任务状态机是什么
Airflow 的每个任务实例都处在一个确定状态：进入队列是 queued，开始执行是 running，结束时是 success 或 failed，失败重试中为 up_for_retry，等待资源为 scheduled，因上游失败为 upstream_failed，被分支跳过为 skipped，交给 deferrable 算子处理为 deferred。排障顺序是先读状态再读日志——状态直接告诉你该往哪查，日志只告诉你这一次执行发生了什么。
基本信息
| 运行态 | queued（排队）、running（执行中）、deferred（延迟等待触发） |
|---|---|
| 终态 | success、failed、skipped、upstream_failed |
| 重试态 | up_for_retry（等待重试）、up_for_reschedule（等待条件检查） |
| 调度的前置态 | scheduled（计划中）、queued（已入队） |
| 查询命令 | airflow tasks states-for-dag-run、airflow tasks list、airflow dags list-runs |
| 查看原因 | airflow tasks failed-deps 可查看上游为何阻止执行 |
典型使用场景
- 任务加厚排查：确定是卡在队列（资源不足）还是卡在执行（业务慢）
- 重试判断：up_for_retry 说明重试次数还没用完，failed 才是真正耗尽
- 依赖排查：upstream_failed 时无需看本任务日志，直接查上游
- 跳过确认：skipped 通常来自分支，不是故障
- 运行核对：用 list-runs 与状态过滤确认某个业务日期是否完整跑完
按状态排查
按状态排查
# 查看某次运行里所有任务的状态（最快的一次总览）
airflow tasks states-for-dag-run daily_orders scheduled__2026-10-11T00:00:00+08:00
# 查看某次运行的任务清单与状态，定位失败项
airflow tasks list daily_orders --tree
# 查上游为何阻止本任务执行
airflow tasks failed-deps daily_orders load_dwd 2026-10-11
# 确认重跑：清理指定区间任务状态后重新调度（选项名以所用版本为准）
airflow tasks clear daily_orders -s 2026-10-11 -e 2026-10-11 -t load_dwd状态读法
| 状态 | 含义 | 下一步动作 |
|---|---|---|
| queued | 已排队等待执行槽位 | 查执行器与资源池是否被占满 |
| running | 正在执行 | 看运行时长与日志，判断是否卡在外部系统 |
| up_for_retry | 失败后等待重试 | 查是否属可自愈的临时故障 |
| failed | 执行失败且重试耗尽 | 读日志定位根因后重跑 |
| upstream_failed | 因上游失败而未能执行 | 转去排查上游任务 |
| skipped | 被分支或规则跳过 | 确认分支条件是否符合预期 |
| deferred | 已让出 worker 等待触发 | 确认触发条件是否按期满足 |
状态为 upstream_failed 时看本任务日志没有意义：它根本没有执行过，问题在上游。这也是很多人白查一小时的原因。
直接清理任务状态会让该区间重新调度，若下游已产出数据可能与新结果混写；重跑前先确认目标分区可被覆盖写。