katherine-wong7 opened a new issue, #68732:
URL: https://github.com/apache/airflow/issues/68732
### Under which category would you file this issue?
Airflow Core
### Apache Airflow version
3.2.2
### What happened and how to reproduce it?
## Issue Description
When a DAG with a `DeadlineAlert` is re-serialized due to a non-deadline
change, the new `serialized_dag` row is inserted with a deadline UUID in its
`data["dag"]["deadline"]` JSON, but no corresponding `deadline_alert` row gets
created. The existing `deadline_alert` row still points at the OLD
`serialized_dag.id`.
When a dagrun is created against the new version, the materialization query
joins on `deadline_alert.serialized_dag_id = <new sd id>` and returns zero
rows. No `deadline` row is materialized. The deadline never fires, the callback
never runs, and the dagrun completes normally with no log or error indicating
the miss.
The bug fires whenever `_try_reuse_deadline_uuids` returns a non-None
mapping (i.e. the deadline definition itself didn't change) AND `write_dag`
proceeds past the hash-equal short-circuit (i.e. some non-deadline part of the
DAG did change). In practice this affects most deadline-bearing DAGs after
their first non-deadline edit.
## How to reproduce
A failing test on `apache/airflow:main` HEAD `9c4908019a`:
https://github.com/katherine-wong7/airflow/blob/kwong/deadline-orphan-test/airflow-core/tests/unit/models/test_serialized_dag.py#L1022-L1078
Fails with:
AssertionError: serialized_dag <uuid> has deadline UUID [<uuid>] in JSON
but no deadline_alert row links to it
The test creates a deadline-bearing DAG, runs it once (so the dag_version
has
task instances, forcing the next write into the INSERT branch), adds a
second
task without touching the deadline definition, re-writes, and asserts the
new
serialized_dag has a linked deadline_alert. The assertion fails on current
`main`.
## Code path
The buggy assignment is at
[`airflow-core/src/airflow/models/serialized_dag.py:663`](https://github.com/apache/airflow/blob/main/airflow-core/src/airflow/models/serialized_dag.py#L663):
```python
if reuse_result is not None:
deadline_uuid_mapping, name_updates = reuse_result
...
dag.data["dag"]["deadline"] = existing_deadline_uuids
deadline_uuid_mapping = {} # <-- empty mapping
```
When the DAG hash also differs (non-deadline change occurred), write_dag
proceeds to either the dynamic-DAG UPDATE branch ([line
754](https://github.com/apache/airflow/blob/main/airflow-core/src/airflow/models/serialized_dag.py#L754))
or the new-row INSERT branch ([line
777](https://github.com/apache/airflow/blob/main/airflow-core/src/airflow/models/serialized_dag.py#L777)).
Both call _create_deadline_alert_records(serialized_dag, {}). That function
early-returns on empty mapping, so no deadline_alert row is created or linked.
PR [#61702](https://github.com/apache/airflow/pull/61702) introduced this
optimization.
### What you think should happen instead?
Every `serialized_dag` row whose `data["dag"]["deadline"]` JSON contains a
deadline UUID should have a corresponding `deadline_alert` row whose
`serialized_dag_id` points at that `serialized_dag.id`. Otherwise the
materialization query at dagrun creation fails to find the alert and the
deadline silently never fires.
### Operating System
macOS 15.7.7
### Deployment
Other Docker-based deployment
### Apache Airflow Provider(s)
_No response_
### Versions of Apache Airflow Providers
_No response_
### Official Helm Chart version
Not Applicable
### Kubernetes Version
_No response_
### Helm Chart configuration
_No response_
### Docker Image customizations
_No response_
### Anything else?
_No response_
### Are you willing to submit PR?
- [ ] Yes I am willing to submit a PR!
### Code of Conduct
- [x] I agree to follow this project's [Code of
Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)
--
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]
