shahar1 opened a new issue, #69035:
URL: https://github.com/apache/airflow/issues/69035
### 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
1. `breeze start-airflow ...` (UI on `:28080`).
2. 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).
3. In the UI go to **Dag Runs**, find the run, and click through to the DAG
→ the detail page shows 500s / infinite loading.
### Related
- #52660 — `/dags/<id>/runs` 500 (`dag_versions should be a valid
dictionary`)
- #49377 — grid HTTP 500 on a `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)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
