MWAA中Airflow任务未执行即失败的原因排查咨询

• 元数据库脏数据或状态不一致：Airflow任务状态完全依赖元数据库，DEV环境可能存在历史失败任务的残留状态，或事务异常导致状态写入错误。可直接查询元数据库task_instance表，查看失败任务的state字段是否异常；也可执行airflow db clean --clean-before-today清理旧任务实例后，重新触发DAG测试。

• 任务并发与资源池挤占：虽实例规格和生产一致，但DEV环境可能同时运行其他测试DAG，导致全局并发、DAG并发或任务池达到上限。用airflow pools list查看任务池使用情况，检查全局配置中core.parallelism、dag_concurrency参数是否和生产完全一致，确认无其他DAG占用过多资源。

• 调度器任务查询竞态问题：当DAG任务量极大时，若调度器max_tis_per_query参数设置过小，会导致多次查询任务实例时出现状态不一致。检查Airflow配置中scheduler.max_tis_per_query的值，确认DEV环境未沿用默认值，而是和生产保持一致。

• 元数据库配置差异：DEV和生产的数据库配置可能存在差异，比如生产用高可用数据库，DEV用单节点且未优化连接池、超时设置。查看数据库日志，检查是否存在锁等待、事务超时、连接数耗尽的情况，这些会导致调度器更新任务状态失败，任务被错误标记为failed。

• Airflow版本或依赖不一致：确认DEV和生产的Airflow版本、Python依赖包完全一致。用pip freeze导出两边的依赖列表对比，排查是否有依赖版本差异导致的状态更新bug，比如部分Airflow版本在大量任务场景下存在状态同步的已知问题。

• 任务实例重复创建与状态冲突：DEV环境可能存在频繁手动触发、外部系统重复触发的情况，导致同一任务的多个实例被创建，状态互相覆盖。检查DAG的concurrency、max_active_runs参数是否和生产一致，查看task_instance表中是否存在同一任务ID的多个实例。

• 工作节点隐性故障：工作节点的系统资源（CPU、内存、磁盘IO）可能存在瓶颈，或网络不稳定导致和调度器的心跳中断，调度器误判任务失败。查看工作节点的系统日志、Airflow Worker日志，检查是否有进程崩溃、连接断开的记录。

• 自定义回调或清理逻辑异常：若DAG中使用了on_failure_callback、on_retry_callback等自定义逻辑或自定义Operator，DEV环境可能因环境变量缺失、权限不足导致回调执行失败，进而错误标记任务为failed。检查这些自定义逻辑在DEV环境的执行情况，确认无环境差异导致的异常。

内容的提问来源于stack exchange，提问作者Raj Rao