github-actions[bot] opened a new pull request, #71133:
URL: https://github.com/apache/airflow/pull/71133
* Resolve serialized exception nodes without importing the stored class name
When deserializing AIRFLOW_EXC_SER / BASE_EXC_SER nodes, BaseSerialization
resolved the exception class with import_string() on a name taken from the
serialized blob. Resolve it against in-memory classes instead, so a stored
DAG never imports a class named in the blob:
- AIRFLOW_EXC_SER: look the name up in a map of loaded AirflowException
subclasses, built once from the in-memory subclass tree; a name that is
not a registered AirflowException subclass is rejected.
- BASE_EXC_SER: resolve against the fixed {KeyError, AttributeError} set
that the encoder is the only producer of.
Unknown or disallowed names raise DeserializationError instead of being
imported. The trigger-node branch is handled separately.
Generated-by: Claude Opus 4.8 following the guidelines at
https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions
* Resolve serialized exception names from loaded modules instead of a
prebuilt map
A prebuilt map keyed on each class's __module__ cannot follow the re-exports
that
import_string used to follow. These exceptions moved to
airflow.sdk.exceptions in
3.2.0, so every blob written by 3.0/3.1 names airflow.exceptions.<Name> and
would
stop deserializing on upgrade.
Reading the name out of an already-loaded module keeps that working, needs
no cache
to go stale when a provider or plugin registers its own subclass late, and
still
refuses to import anything the stored blob names.
* Condense the docstrings around exception-name resolution
Review feedback: the explanation was longer than the behaviour it describes.
(cherry picked from commit 3a08a3d7792335ac9456cd44c92d8de3ae0d6ec1)
Co-authored-by: Jarek Potiuk <[email protected]>
--
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]
