Show per-Dag run state counts on the Dags list page

[yuseok89]

closes: #66946

Each Dag card and table row on the Dag list page now shows four clickable run-state badges(success, failed, running, queued). Clicking a badge navigates to /dags/<id>/runs?state=<state> with the filter pre-applied, restoring the "scan → click → filtered runs" workflow from Airflow 2.

What changed

• New endpoint GET /api/v2/ui/dags/run_state_counts: for the requested Dag IDs it runs one capped UNION ALL per state, each branch (one per Dag) reading at most 1,000 rows, then groups by dag_id. dag_ids is bounded to the API max page limit so the union width can't grow unbounded.
• Card view: state badges rendered below the recent-runs bar chart.
• Table view: compact badges in a new "Run states" column.
• Large counts: once a count reaches the 1,000 cap, the badge shows it as 1000+ instead of an exact total.

No time window applied

All-time counts are returned as-is. The concern raised in #50624 (that years of accumulated runs become noise) is worth discussing. If reviewers prefer a default window (e.g. 7d or 30d), I'm happy to add one; I intentionally left this open rather than picking an arbitrary default. Feedback on a reasonable window size is welcome.
Counts reflect all runs (capped per state). A time-range selector was considered but removed, since it could be confusing for users.

Demo

Screen.Recording.2026-07-01.at.1.28.58.AM.mov

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)
  • Opus 4.7

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[choo121600]

Personally, the space below the DagRun bar chart feels a bit awkward. What do you think?
For the window size, I think it would be better if users could configure it themselves. However, I think this part may need further discussion with the other reviewers.

[yuseok89]

@choo121600
Thanks for the review!

Personally, the space below the DagRun bar chart feels a bit awkward. What do you think?

Agreed, the space below the bar chart felt awkward. What do you think of this layout instead?

For the window size, I think it would be better if users could configure it themselves. However, I think this part may need further discussion with the other reviewers.

As for the window size, I'd love to keep the discussion going here. One middle ground could be offering a fixed set of server-enforced options (e.g. 24h / 7d / 30d / All) so users have flexibility without the risk of extreme values. Would be great to hear what other reviewers think as well.

[bbovenzi]

Nice work!
We could also move Latest Run and Next Run into a single column.

We have a few date range selectors already in the UI ("dashboard" and "overview" pages). So let's try to reuse those

[yuseok89]

@bbovenzi
Thanks for the review!

Screen.Recording.2026-05-23.at.11.12.14.PM.mov

As shown in the attached video, I think we can reuse the existing TimeRangeSelector component as-is (Last Hour / Last 12 Hours / Last 24 Hours / Past Week). The date range text is hidden here since it's not needed in this context.

One thing I'd like your thoughts on. If we add this dropdown, would it make sense to also sync it with the existing run history graph (the bar chart on each Dag card) and other filters? The bar chart currently shows the most recent N runs regardless of time window, so it might feel inconsistent if the state count badges are filtered but the graph isn't.

Also, I want to make sure I understand the "Latest Run + Next Run into a single column" suggestion correctly. Are you proposing to consolidate those two into one column to free up horizontal space, with the idea of fitting the state count badges into the same row rather than a separate row below?

[choo121600]

It looks like static check is failing, could you please take a look?

[choo121600]

and also looks like a rebase on main is needed :)

[pierrejeambrun]

Thanks for the rework — all the earlier points are addressed and this looks ready. One small thing: the time-range selector was dropped from the Dags list (good), but the change to the shared TimeRangeSelector.tsx (the new showDateRange prop) doesn't seem to be used anywhere now. Could we revert that file so the shared component doesn't carry an unused prop? After that I think we're good to merge.

Also we rely on the 'list' refetching / being invalidated, to modify the 'useAutoRefresh' value and therefore trigger a refresh. If auto_refresh_interval is disabled, this will never refetch triggering a dag and the count will be stale. (Manual refresh will have to happen)

[yuseok89]

Thanks for the rework — all the earlier points are addressed and this looks ready. One small thing: the time-range selector was dropped from the Dags list (good), but the change to the shared TimeRangeSelector.tsx (the new showDateRange prop) doesn't seem to be used anywhere now. Could we revert that file so the shared component doesn't carry an unused prop? After that I think we're good to merge.

Also we rely on the 'list' refetching / being invalidated, to modify the 'useAutoRefresh' value and therefore trigger a refresh. If auto_refresh_interval is disabled, this will never refetch triggering a dag and the count will be stale. (Manual refresh will have to happen)

Really grateful for how much time you put into this across so many iterations.
Your early review on scalability was the turning point.
It steered the whole approach somewhere much more solid, and I learned a lot from it.
The unused showDateRange prop is gone from the shared TimeRangeSelector now.
For the stale-count case when auto-refresh is off, I'll pick it up separately.

[pierrejeambrun]

Thanks for the work you put into this. I'm sure people will really like it. (They missed the old AF2 summary)