Task duration tooltip is incorrect for a running task with previous tries

[zachliu]

Apache Airflow version

3.1.8

If "Other Airflow 3 version" selected, which one?

No response

What happened?

For a running task, the duration in its tooltip is not calculated but just a copy from previous try.

What you think should happen instead?

The duration for a running task should be calculated and reflected in its tooltip.

How to reproduce

Re-run a finished task and see its tooltip in the grid view.

Operating System

LM 21.3 with docker python:3.12-slim-bookworm

Versions of Apache Airflow Providers

No response

Deployment

Docker-Compose

Deployment details

No response

Anything else?

No response

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

[tirkarthi]

This looks like an issue from the backend response where if a task is retried then the task_instance_history doesn't immediately create an entry but the task_instance table is updated with the try_number and the duration remains the same. Hence on tries endpoint it takes the existing tries and adds the current task instance which doesn't have duration reset but holds on to the last try's duration value.

airflow/airflow-core/src/airflow/api_fastapi/core_api/routes/public/task_instances.py

Lines 342 to 346 in 56090bd

	# Exclude TaskInstance with state UP_FOR_RETRY since they have been recorded in TaskInstanceHistory
	tis = session.scalars(
	_query(TI).where(or_(TI.state != TaskInstanceState.UP_FOR_RETRY, TI.state.is_(None)))
	).all()
	task_instances = list(session.scalars(_query(TIH)).all()) + list(tis)

mysql> select try_number, start_date, task_id, state, run_id, duration from task_instance where task_id = "fail_task" order by run_id;
+------------+----------------------------+-----------+---------+--------------------------------------+----------+
| try_number | start_date                 | task_id   | state   | run_id                               | duration |
+------------+----------------------------+-----------+---------+--------------------------------------+----------+
|          2 | 2026-03-14 19:41:00.203532 | fail_task | running | scheduled__2026-03-14T01:00:00+00:00 |  43.7898 |
+------------+----------------------------+-----------+---------+--------------------------------------+----------+
1 row in set (0.01 sec)

mysql> select try_number, start_date, task_id, state, run_id, duration from task_instance_history where task_id = "fail_task" order by run_id;
+------------+----------------------------+-----------+--------+--------------------------------------+----------+
| try_number | start_date                 | task_id   | state  | run_id                               | duration |
+------------+----------------------------+-----------+--------+--------------------------------------+----------+
|          1 | 2026-03-14 19:40:00.024494 | fail_task | failed | scheduled__2026-03-14T01:00:00+00:00 |  43.7898 |
+------------+----------------------------+-----------+--------+--------------------------------------+----------+

from __future__ import annotations

from datetime import timedelta

from pendulum import datetime

from airflow.exceptions import AirflowException
from airflow.sdk import DAG, task

with DAG(
    dag_id="gh63573",
    schedule="0 1 * * *",
    start_date=datetime(2026, 1, 1),
    catchup=False,
    default_args={"retries": 3, "retry_delay": timedelta(seconds=10)},
):

    @task
    def fail_task():
        import time

        time.sleep(1000)
        raise AirflowException("fail")

    fail_task()

[Subham-KRLX]

@tirkarthi Great investigation! You're right that the backend holds onto the previous try's duration.
A clean way to fix this without changing backend logic is to dynamically calculate the duration in the UI for running tasks. I'll put up a PR that updates TaskInstanceTooltip.tsx to use the getDuration utility for live calculation when the state is running or deferred.