GitHub user seunggihong added a comment to the discussion: Clearing tasks from old DAG runs resets start_date instead of preserving original
### 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 #30125** (linked to GitHub Issue #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 #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. GitHub link: https://github.com/apache/airflow/discussions/55206#discussioncomment-14303274 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
