Apache Airflow version
main (3.x), reproduced on a recent breeze start-airflow build.
What happened
When a DAG is executed via dag.test() — directly, or through the system-test harness tests_common.test_utils.system_tests.get_test_run — against a shared metadata DB, the run path writes a DagRun, a DagModel, and a SerializedDagModel under the synthetic bundle name testing. The DAG's source file is not in any configured DAG bundle, so the dag processor never parses it.
In the UI this produces an inconsistent, broken state:
- The DAG does not appear in the Dags list (nothing parsed it).
- Its run is visible under Dag Runs / History.
- Opening the DAG detail page (
/dags/<dag_id>) produces repeated HTTP 500s, infinite loading spinners, and intermittent "error 500" popups when navigating its links/sub-pages.
GET /ui/grid/<dag_id> returns 200, so the failure is on the detail/metadata endpoints that try to resolve the DAG's bundle / source / definition, which do not exist for a record that only lives under the synthetic testing bundle.
What you think should happen instead
The UI should handle a DAG that has run history but no live/parsed definition gracefully — e.g. render the existing runs plus a clear "definition not currently available / not parsed" state — instead of returning 500s and looping. The same situation applies to a DAG that was removed from its bundle but still has historical runs.
How to reproduce
breeze start-airflow ... (UI on :28080).- Run any system test against the same metadata DB, e.g.
pytest --system providers/google/tests/system/google/cloud/.../example_*.py
(or add if __name__ == "__main__": dag.test() to a DAG file that is not in the dags folder and run it).
- In the UI go to Dag Runs, find the run, and click through to the DAG → the detail page shows 500s / infinite loading.
Related
Both are the same class of problem: a DAG present in the DB but not fully backed by a parsed/bundled definition causing UI 500s.
Notes
Cleanup/workaround for an affected record: airflow dags delete <dag_id>.
Drafted-by: Claude Code (Opus 4.8) (no human review before posting)
Apache Airflow version
main (3.x), reproduced on a recent
breeze start-airflowbuild.What happened
When a DAG is executed via
dag.test()— directly, or through the system-test harnesstests_common.test_utils.system_tests.get_test_run— against a shared metadata DB, the run path writes aDagRun, aDagModel, and aSerializedDagModelunder the synthetic bundle nametesting. The DAG's source file is not in any configured DAG bundle, so the dag processor never parses it.In the UI this produces an inconsistent, broken state:
/dags/<dag_id>) produces repeated HTTP 500s, infinite loading spinners, and intermittent "error 500" popups when navigating its links/sub-pages.GET /ui/grid/<dag_id>returns200, so the failure is on the detail/metadata endpoints that try to resolve the DAG's bundle / source / definition, which do not exist for a record that only lives under the synthetictestingbundle.What you think should happen instead
The UI should handle a DAG that has run history but no live/parsed definition gracefully — e.g. render the existing runs plus a clear "definition not currently available / not parsed" state — instead of returning 500s and looping. The same situation applies to a DAG that was removed from its bundle but still has historical runs.
How to reproduce
breeze start-airflow ...(UI on:28080).pytest --system providers/google/tests/system/google/cloud/.../example_*.py(or add
if __name__ == "__main__": dag.test()to a DAG file that is not in the dags folder and run it).Related
/dags/<id>/runs500 (dag_versions should be a valid dictionary)dag.test-run integration-test DAG (dynamic-task-mapping cause)Both are the same class of problem: a DAG present in the DB but not fully backed by a parsed/bundled definition causing UI 500s.
Notes
Cleanup/workaround for an affected record:
airflow dags delete <dag_id>.Drafted-by: Claude Code (Opus 4.8) (no human review before posting)