Clearing tasks from old DAG runs resets start_date instead of preserving original

[Komalpawar22]

DAG run start_date is overwritten when clearing old tasks

Apache Airflow version

2.10.4

---

What happened

When clearing a task from an old DAG run, the DAG run’s start_date gets updated to the current timestamp.
This makes the old run appear as if it just started “today,” even though it originally ran days or weeks ago.

---

What you expected to happen

• The DAG run’s start_date should remain fixed to its original value (when the run was first created).
• Only the end_date or task-level timestamps should update when clearing/retrying tasks.
• start_date should act as an immutable record of when the DAG run first started.

---

How to reproduce

1. Trigger a manual DAG run (e.g. manual__2025-07-25T00:00:00+00:00).
2. Note the run’s start_date.
3. Wait (days/weeks).
4. Clear one of the tasks in that old run.
5. Observe that the DAG run’s start_date is now updated to the current time.

---

Anything else

• This behaviour feels confusing and counterintuitive.
• From a user perspective, start_date looks like a historical field and shouldn’t change after the fact.
• Is this behaviour intended?
• If not, are there any fixes or changes in newer versions of Airflow?

---

Attachments

This DAG is scheduled daily.

[seunggihong]

1. Is this behavior intended or a bug?

• For running/queued DAG runs, resetting start_date on Clear was a bug and was fixed by PR Prevent DagRun's start_date from reset (#30124) #30125 (linked to GitHub Issue DagRun's start_date updated when user clears task of the running Dagrun #30124).
  After this fix, clearing tasks should not reset the DAG run’s start_date while the run is still active.

• However, when you clear tasks on an already finished DAG run (e.g., weeks old, in success/failed), Airflow re-queues that run to re-execute it.
  In this scenario, start_date reflects the (re)start moment of that run, so it can be updated to “now”.
  This is by design: start_date indicates when this DAG run (attempt) started, not a strictly immutable historical stamp.

If you need an immutable historical reference, rely on logical_date (a.k.a. execution_date) rather than start_date.

2. What versions contain the fix?

• The bug fix for running/queued runs (do not reset start_date on Clear) landed via PR Prevent DagRun's start_date from reset (#30124) #30125 and has been in 2.6.x+ and thus is present in 2.10.x as well.

3. Workarounds or alternative fields

• Use immutable fields for historical context:
  • Manual triggers: execution_date / logical_date
  • Scheduler-based runs: data_interval_end (or logical_date)
• Treat start_date as “when this run attempt began”, which can validly change when you re-run an old DAG run.

4. Recommendations

• On Airflow 2.10.x, your observation (old finished run’s start_date updated on Clear) is expected when the run is being re-run.
• If you want to display the original start moment in your UI or metrics, surface logical_date (and/or store your own immutable audit timestamp) instead.