itej13 commented on code in PR #69099:
URL: https://github.com/apache/airflow/pull/69099#discussion_r3490150882
##########
airflow-core/src/airflow/models/dagbag.py:
##########
@@ -104,7 +107,14 @@ def __init__(
def _read_dag(self, serdag: SerializedDagModel) -> SerializedDAG | None:
"""Read and cache a SerializedDAG (with its ``dag_hash`` for staleness
detection)."""
serdag.load_op_links = self.load_op_links
- dag = serdag.dag
+ try:
+ dag = serdag.dag
+ except Exception:
Review Comment:
Following up — CI caught something more fundamental than the breadth of the
catch, and it changed the approach.
The 4 failing jobs were all
`TestDagErrorHandler::test_handle_real_dag_deserialization_error`. That test
exists because the codebase **already** routes `DeserializationError` to an
app-wide `DagErrorHandler` (registered in `core_api/app.py`) that renders a
consistent, safe response. My `_read_dag` catch was swallowing
`DeserializationError` and returning `None` (→ 404), which bypassed that
handler and broke its contract. So "convert to 404" was both the wrong layer
and a policy the codebase had already decided against.
I've reworked it: instead of catching at `_read_dag` and returning 404, I
now **normalize** the sibling failures that currently escape the handler as
unhandled raw 500s — unknown `__version` (`ValueError`), missing top-level
`dag` key (`KeyError`), bad JSON, `TimetableNotRegistered`, corrupt compressed
column (`zlib.error`) — into `DeserializationError`, so every deserialization
failure flows through the existing `DagErrorHandler` and is handled
identically. `DeserializationError` is no longer caught (it already
propagates), and unrelated errors (DB failures, serving-path bugs) are left
untouched — addressing your original concern about masking.
Verified end-to-end: a valid Dag returns 200, a corrupt blob now returns the
handler's graceful 500 instead of a raw one. Updated the PR title/description
to match.
---
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]
