[yuseok89]

closes: #66947

Each Dag card and table row on the Dags list now shows the task instance states of the Dag's recent runs as clickable badges, like the "Recent Tasks" column in Airflow 2. The counts cover all running Dag runs, or the most recent run when none is running. Clicking a badge opens the task instance list filtered to those runs and that state.

What changed

• New endpoint: GET /ui/dags/recent_task_instance_state_counts. It takes the latest run ids the Dag list already returns (dag_run_ids, bounded by the API max page limit) and counts, in one statement, the task instances of each Dag's running runs, or of that latest run when none is running. Each entry returns the counted run_ids and the state_counts.
• Card view: he badges appear in the card's second row, under Latest Run and Next Run, next to the run state badges.
• Table view: a new "Recent tasks" column with an info tooltip explaining what is counted. The badges stay on one line.
• Dynamic badges: only the states present are shown, ordered by priority. Task instances with no state yet appear as no_status.
• Links: each badge opens Task Instances filtered by the Dag, the counted run ids and the state. These are pattern filters, so another Dag whose id starts with this one and shares a run id can also show up.
• Setting: "Show recent tasks" (on by default) hides the column and badges and skips the request entirely.

Unlike the run state badges from #67242, which count a Dag's runs by state, these count the task instances of its recent runs.

Query performance

The counts come from a single statement whose size does not grow with the number of running runs. Running runs are found through the partial idx_dag_run_running_dags index and their task instances through ti_dag_run, so the cost scales with the task instances actually counted. In a local benchmark (postgres 14, Airflow's indexes, 100 Dags × 1,050 runs × 30 tasks), it was roughly 40 to 75 times faster than counting with one UNION ALL branch per run once Dags had 50 running runs each. Absolute timings depend on the machine.

Demo

Screen.Recording.2026-10-05.at.10.06.37.PM.mov

---

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

• Yes (please specify the tool below)
  • Claude Code (Opus 5.5)

---

• 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.

[bbovenzi]

Thanks for opening this.

Let's make sure dags list performance issues are resolved first. Like in this PR: #69806. Only after that should we add any more complexity to the dags list

[yuseok89]

Thanks for opening this.

Let's make sure dags list performance issues are resolved first. Like in this PR: #69806. Only after that should we add any more complexity to the dags list

Makes sense, thanks. I'll take a look at the dags list performance work too and see if there's anything I can help with there.

[yuseok89]

Hi @bbovenzi.
The dags list performance work is now resolved (#69806 merged, #69609 closed).
So would this be a good time to pick it back up?

[pierrejeambrun]

Can you benchmark this when there are millions of TI and hundred of thousand of runs in the DB?

I would like to double check performance, my feeling is that it will not scale way because of the subqueries

[bbovenzi]

Let's just have it always be one line. I'd rather not maintain logic saying, "if this dag isnt running, then let it be two lines" that sounds very easy to mess up and break.

[yuseok89]

I opened the single-line change for the existing columns separately in #74002, since it felt a bit different in scope from this PR. With that applied and the latest run tasks also kept on one line, the table could look like this.

Option 1 (only the states present in the run)

Screen.Recording.2026-10-01.at.8.14.28.PM.mov

Keeping everything on one line reminded me of Airflow 2, so I also tried listing every state in a fixed position the way Airflow 2 did, with the empty ones dimmed. Personally, I don't think it looks as good.

Option 2 (every state)

I'll go ahead with the first option and work on the toggle next.
Please let me know anytime if you see it differently.

[pedro-cf]

Would it be a problem/bad idea/anti-pattern if the icons were disabled the table view (and possibly card) ?

Also regarding the "Latest Run tasks", would it be possible to make it similar to Airflow 2 where it showed: "Status of tasks from all active DAG Runs or, if not currently active, from most recent run."

[yuseok89]

Thanks @pedro-cf!

About the icons, as far as I know the state badge hasn't been used without its icon since it was introduced, so it has been used much like a standard across the UI. If we dropped the icons only here, I wonder if this column would feel a bit out of tone with the rest of the UI.

About the description, I couldn't find a precedent for one on a table column header, but I'll give it a try.

[pedro-cf]

Thank you very much for your wonderful work @yuseok89

About the description, I couldn't find a precedent for one on a table column header, but I'll give it a try.

Regarding this, my concern is whether you are displaying only the tasks from the "Latest Run", rather than the "status of tasks from all active DAG Runs or, if not currently active, from the most recent run." If so, would it be possible to change it to the latter?

[yuseok89]

Thanks for clarifying!
Yes, it currently shows only the tasks from the latest run. I think I misunderstood what the Recent Tasks column showed in Airflow 2. I'll look into making it behave the same way. From the code, it doesn't look like it would cause performance issues, so I'll give it a try.

[yuseok89]

Hi @bbovenzi @pedro-cf, I've addressed the feedback so far.

• The task states in the table now always stay on a single line, with no logic that depends on whether the Dag is running. Keeping the other table columns on a single line is handled separately in UI: Keep Dags list table rows on a single line #74002, since it changes the existing columns rather than this feature.
• A "Show recent tasks" toggle in the user settings turns the counts off entirely. When it's off, the UI doesn't send the request, so the query never runs.
• Like the Recent Tasks column in Airflow 2, the counts now cover all running Dag runs, or the most recent run when none is running. The column is renamed to "Recent tasks", and an info tooltip next to its header explains what is counted and that it can be turned off in the user settings.
• Updated the PR description and the demo video to match.

Could you take another look when you have a moment?

[yuseok89]

Resolved the conflicts with main. After resolving them,DagsList.tsx went over the 500-line lint limit, so I moved the table columns into a new DagsListColumns.tsx in a separate commit. The moved code is unchanged, so that commit can be reviewed on its own.

[yuseok89]

Thanks @bbovenzi @pierrejeambrun @pedro-cf for the reviews. Your feedback helped me get this to a much better place than where it started, and I learned a lot along the way.