Add filters to Task Instances Tab

[Pei-Cheng-Yu]

Related issues

closes: #53051

TODO:

Filters:

• Filters to Add
• Filter by Run ID
• Filter by Queue
• Filter by Pool
• Filter by Operator Type
• Filter by Duration Range
• Filter by Logical Date (from DAG Level)
• Filter by Try Number
• Filter by Mapped Index
• Filter by DAG Version

API:

already done by [#53042]

Screenshots

since filter for Task Instances at Task View and Search View are the same one, some demo clip is record on Search View for larger data set, showing the fuctionality

conf.mp4

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[Pei-Cheng-Yu]

Implenting multiselect filter for Queue, Pool, Operator like [#54484], while using Pill Filter for other params that is suit for sigle-selection, like others filter

[bbovenzi]

Thanks for taking this on. I think we can break this into smaller PRs.

First to move all filters into FilterBar and quickly add any simple filters that already exist in filterConfigs.tsx.

Second, to add new filter configs.

[Pei-Cheng-Yu]

UPDATE

integrated state, operator, pool, queue filter into FilterBar

TODO

• move searchBar to FilterBar
• move queue to FilterBar
• move state to FilterBar
• move pool to FilterBar
• move operator to FilterBar

FollowUp

want make sure that, in local when i testing with prek, the Compile / format / lint UI test show
274:1 error File has too many lines (290). Maximum allowed is 250 max-lines
for the filterConfigs.tsx, should I refactor the filterConfigs.tsx, sperate it into several one, like DagFilterConigs, DagRunFilterConfigs... etc? or any suggestion for dealing with it?

[Pei-Cheng-Yu]

Hi @bbovenzi — thanks again for the review! I’ve addressed all requested changes.

I’ve integrated state / operator / pool / queue into FilterBar (see UPDATE + screenshot).

Follow-up: while testing locally with prek, ESLint reports:
filterConfigs.tsx:274:1 File has too many lines (290). Maximum allowed is 250 max-lines

Would you prefer I refactor that in this PR, or open a separate PR to keep this one focused on the original issue? First time contributing to this repo, so I want to follow the preferred workflow.

I can do either. Let me know your preference or any suggestions. Thanks!

[pierrejeambrun]

Thanks for the PR.

Looks nice overall. A few things to address before we can merge.

The main problem being that we show 'search bar' for a few different filter where those filters are actually not 'search' in the backend but plain 'filter'. This means that until you fully typed the correct name in the search bar, nothing will be returned.

We can either convert UI filters to not use the searchbar and populate dropdowns somehow, or implement the search / pattern match counterpart filers in the backend for pool, queue etc... I think we should go with the backend filter solution, that could be a very simple separate PR. Or I can do it if you want, just let me know.

[Pei-Cheng-Yu]

Hi @pierrejeambrun , Thanks for the review!
That makes sense — I’ll work on adding the backend filter support (for pool, queue, etc.) in a separate PR and link it here and to the issue.

[Pei-Cheng-Yu]

UPDATE:

• Fix "All_state" option bug, it now clear the state filter, instead of pass value to the filter
• Change Pool, Queue, Operator to name pattern filter, and make the commit history cleaner (clean up duplicate commits)

FollowUp:

• I just realize that the state filter on the "Dag Runs" veiw page has the same issue ( choosing "All State" option for filter will cause error) , should I open a new PR for that?
• I also found that run_id has the same problem as the old versions of Pool, Queue, and Operator. It’s not a name pattern filter, so users have to type the full ID to filter. I’m planning to open a PR soon to add a backend filter solution for run_id.

[RoyLee1224]

Overall looks great!
Just one nit about translation💪

[guan404ming]

Overall looks good in my local test

[guan404ming]

@RoyLee1224 could you help take another look? Thanks!

[guan404ming]

One minor note: the dropdown looks a little too information-dense now. I think we can address this in follow-up PRs to make it cleaner.

Make sense to me.

[Pei-Cheng-Yu]

Hi @guan404ming, @RoyLee1224,
Thanks for the review, I really appreciate it! During my final local testing I noticed that run_id is actually a search filter, not a pattern filter — my mistake.
I’ll open a new PR for the run_id_pattern backend solution, and then come back to fix this PR after that one is merged.
Appreciate your help checking it once it’s up. Thanks!

[guan404ming]

I think let's just integrate the fix into this PR since this one is not merged, what do you think?

[Pei-Cheng-Yu]

No problem! I'll integrated it very soon

[bbovenzi]

Just merged the date-range filter if we want to use it here

[Pei-Cheng-Yu]

Hi @bbovenzi, thanks for the review. Really appreciate your help!, I just merge the date range picker

[pierrejeambrun]

LGTM, thanks

Change were address