UI: Task instance state badge stays stale after Mark-as action

[neochaotic]

Under which category would you file this issue?

Airflow Core

Apache Airflow version

3.2.2

What happened and how to reproduce it?

After marking a single task instance as failed (or success) from
the Task Instance page, the state badge in the header keeps showing
the previous state. A hard refresh is required to see the new state.
The grid view stays stale as well. Marking a DAG Run as failed/success
works correctly — only the task-instance Mark-as is affected.

Steps to reproduce

1. Start Airflow 3.2.2 standalone with examples enabled:
   docker run -e AIRFLOW__CORE__LOAD_EXAMPLES=true -p 9080:8080 apache/airflow:3.2.2 standalone
2. Unpause example_dag_decorator and trigger a run.
3. Wait for echo_ip_info to finish with success.
4. Open the task instance page:
   /dags/example_dag_decorator/runs/<run_id>/tasks/echo_ip_info
5. Click the ✓ / ✗ menu (top right) → pick failed → confirm.

The header badge keeps showing success until hard refresh.

What you think should happen instead?

The header state badge and the grid cell should reflect the new state
immediately after the action confirms, the same way the DAG Run
Mark-as flow already does.

What I have verified

• Server is correct. A direct PATCH then GET via curl returns the
  new state on the next read:
  • PATCH /api/v2/dags/example_dag_decorator/dagRuns/<run>/taskInstances/echo_ip_info?map_index=-1 → 200, body shows "state": "failed".
  • GET /api/v2/dags/example_dag_decorator/dagRuns/<run>/taskInstances/echo_ip_info/-1 → 200, "state": "failed".
• The SPA refetch fires. DevTools Network shows the singular
  mapped-TI GET .../-1 triggered right after the PATCH (200 OK, 0.8 kB),
  plus refetches for the grid stream and dag details.
• The SPA receives the new state. The Response body of that GET
  contains "state": "failed", so the TanStack cache should have the
  fresh data.
• Despite this, <HeaderCard state={taskInstance.state}> in
  pages/TaskInstance/Header.tsx keeps rendering the previous state.
  The grid summary cells remain stale too.

This points to a cache-to-observer / render-equality issue downstream
of invalidateQueries, not at the API or invalidation-key layer.

Operating System

macOS 15.5 (apache/airflow:3.2.2 container)

Apache Airflow Provider(s)

n/a — Airflow Core (UI) only.

Versions of Apache Airflow Providers

n/a

Deployment

Other Docker-based deployment

Deployment details

docker run -e AIRFLOW__CORE__LOAD_EXAMPLES=true -p 9080:8080 apache/airflow:3.2.2 standalone

Anything else?

• Reproduces every time on every TI in every DAG tested
  (example_dag_decorator, example_bash_operator).
• Only affects Task Instance Mark-as; DAG Run Mark-as updates the
  header badge correctly.
• Closed PR Fix Grid cache invalidation for multi-run task operations #55504 fixed a related family of stale-grid bugs for the
  Clear action; this looks like a sibling case for Mark-as that was
  not covered.
• The code on main is identical to 3.2.2 in this area — the bug
  also exists on main HEAD.

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

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

[boring-cyborg]

Thanks for opening your first issue here! Be sure to follow the issue template! If you are willing to raise PR to address this issue please do so, no need to wait for approval.

[neochaotic]

After further investigation, this bug appears to have been fixed on main by
PR #67212 (Improve query validation, including for streaming, merged 2026-05-20), which adds a
queryClient.getQueryCache().subscribe(...) watcher in
useGridTISummaries.ts that re-streams the grid whenever any
grid-related query key is invalidated.

That PR carries the backport-to-v3-2-test label and was milestoned for
3.2.2, but the 3.2.2 release was tagged on 2026-05-26 without it, so the
fix is currently only on main.

Confirmed by checking out main HEAD locally and running through the same
repro — the header state badge updates immediately after the mark-as
action, no hard refresh needed. On apache/airflow:3.2.2 (the standalone
image) the bug still reproduces every time.

Could a maintainer trigger the backport of #67212 to v3-2-test so the
fix lands in the next 3.2.x release? Happy to help open the cherry-pick PR
if useful.