naruto-lgtm commented on PR #68662: URL: https://github.com/apache/airflow/pull/68662#issuecomment-5083398262
On wider implications, I went back through the surfaces this could touch. `BaseSerialization` is the Dag serialization framework, so its persisted output is the `serialized_dag` table. The two stores you'd normally worry about don't go through it: XCom values are encoded by `XComEncoder` in `airflow/utils/json.py`, which delegates to `airflow.sdk.serde`, and trigger kwargs are serialized with `airflow.sdk.serde` as well in `models/trigger.py`. Neither path ever produced or read an `airflow_exc_ser` blob, so dropping the branch doesn't reach them. `AIRFLOW_EXC_SER` and `BASE_EXC_SER` are referenced only in `serialized_objects.py` and its own tests. No provider and no task-sdk code references either member, so nothing out of tree is decoding them by name. The exceptions' own `serialize()` methods don't go dead either. The hash-stable fingerprint helper (`serialize_object` in `serialization/helpers.py`, and the task-sdk copy in `task_runner.py`) dispatches duck-typed on anything exposing `serialize()` and only folds the result into a JSON structure. It never imports and calls a class, so that path is unaffected and Dag hashes don't move. The one sharp edge worth naming: for an exception to be in a `serialized_dag` row at all it has to be reachable from a Dag-level value, so a param default, something in `default_args`, an operator attribute. If such a row was written by an older version, reading it back now raises `TypeError: Invalid type ...` instead of reconstructing. New rows are written when the Dag hash changes, but older DagVersion rows stick around, so it isn't fully self-healing. My read is that failing loudly is the right behaviour there and it's hard to hit in practice, but if you'd rather no read path can raise, I can add a tolerant decode that returns the string form for those two legacy type tags. Happy to push that if you prefer it. CI is green on the current head. -- 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]
