[Feature][API][UI] Add a read-only task search to locate which workflow a task belongs to

[llphxd]

Search before asking

• I had searched in the issues and found no similar feature requirement.

Description

In DSIP-59 the standalone Task Definition page was removed from the project menu, along with its backend list/search endpoints. This was a reasonable architectural decision.
However, that removal also deleted the only entry point to answer a very common operational question:

▎ "Given a task name, which workflow(s) does it belong to?"

I'm not asking to bring back the old management page (create / edit / run standalone tasks). I'm asking for a read-only search that maps a task name to its parent workflow(s).

Use case

In big-data environments, task names usually follow strict naming conventions (e.g. one task per table, task name ≈ table name). Operators frequently need to start from a task/table name and jump to the workflow that owns it — for troubleshooting, impact analysis, or verifying a migration. After DSIP-59 there is no UI or REST entry for this, even though the relationship is still fully present in the metadata DB:

SELECT p.name AS project, wd.name AS workflow, wd.code AS workflow_code,
       td.name AS task, td.task_type
FROM t_ds_task_definition td
JOIN t_ds_workflow_task_relation wtr ON td.code = wtr.post_task_code
JOIN t_ds_workflow_definition wd     ON wtr.workflow_definition_code = wd.code
                                    AND wtr.project_code = wd.project_code
JOIN t_ds_project p                  ON wd.project_code = p.code
WHERE td.name LIKE CONCAT('%', ?, '%');

The data is there; only the entry point is missing.

Why the existing Task Instance page is not enough

The Task Instance page can partially help, but it can only surface tasks that have executed. It cannot locate:

• tasks that have never run (newly created, or never scheduled);
• tasks whose instances have already been purged by retention / periodic cleanup;
• the current definition of a recently modified task — instances reflect the historical version captured at run time, not the latest task definition.

So Task Instance search misses exactly the cases where "find the owning workflow by name" is most needed.

Proposal (read-only, aligned with DSIP-59)

• Add a lightweight, read-only task search page under the project's Task submenu (next to Task Instance).
• Input: task name (fuzzy match), scoped to the current project.
• Output: a paginated list of task name | task type | owning workflow (clickable link)n jump straight into the workflow.
• Backend: a single read-only paginated query endpoint (the relation already exists via t_ds_workflow_task_relation); no write paths, no standalone-task creation — so it does not reintroduce the orphan-task problem DSIP-59 solved.

Use case

No response

Related issues

DSIP-59

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[SbloodyS]

+1, this is a good proposal. Howerer, Fuzzy query using like in database will lead to index invalidation, which is not a good way.

[llphxd]

+1, this is a good proposal. Howerer, Fuzzy query using like in database will lead to index invalidation, which is not a good way.

Thanks @SbloodyS , that's a fair concern.But as far as I can tell, this is pretty much how name search already works across DS today:
workflow instances, task instances, workflow definitions, and the task group queue all
use a plain name LIKE '%...%'. So reusing the same approach here felt like the most consistent option rather than introducing something new.

There's also TaskDefinitionMapper#filterTaskDefinition, which already does exactly this
query and has been unused since DSIP-59 — seems like a natural fit to just reuse.