Airflow fail-fast DAG changes can trap a scheduler

Changing a DAG definition is a deployment, even when the code diff is only a task name. An open Airflow issue reports a scheduler crash loop when a task is removed or renamed while an unversioned fail_fast DAG has a running execution and another task fails. The report points to a specific main/3.3.2 path. It should be treated as a versioned risk to reproduce, not a universal Airflow rule.

Inventory active runs before a rename

List running and queued DAG runs, their task instance states, the current task IDs and the proposed definition. A removed task may already have an instance in an active run. Airflow’s task and DAG documentation describes how task state relates to the current DAG definition; check the exact deployed version and bundle strategy.

Reproduce in staging

Use a small fail_fast DAG with one long-running task and one task that can fail. Start a run, then deploy a definition with a renamed or removed task and trigger the failure. Observe scheduler logs, health checks and the DAG run outcome. Keep the test isolated from shared production scheduling.

Sequence the rollout

If the installed version reproduces the issue, wait for affected runs to finish or use a documented versioned DAG deployment path before removing task IDs. Keep a rollback artifact and monitoring window. A task rename should be reviewed for run continuity just like a schema change.

Adovo’s view

A running workflow has memory of its old shape. Deploying a new shape into that run is a compatibility decision, not a cosmetic refactor. Protect the scheduler by testing the transition state, where failures and deployments overlap.