potiuk commented on code in PR #72651:
URL: https://github.com/apache/airflow/pull/72651#discussion_r3999399253
##########
airflow-core/src/airflow/serialization/decoders.py:
##########
@@ -182,15 +182,125 @@ def decode_deadline_reference(reference_data: dict):
return reference_class.deserialize_reference(reference_data)
+_TIMEDELTA_CLASSNAME = "datetime.timedelta"
+_VARIABLE_INTERVAL_CLASSNAMES = frozenset(
+ {
+ "airflow.sdk.definitions.deadline.VariableInterval",
+
"airflow.serialization.definitions.deadline.SerializedVariableInterval",
+ }
+)
+
+
+def _normalised_payload(encoded: Any, field: str) -> tuple[str, Any]:
+ """
+ Return ``(classname, data)`` for a serde payload, in either encoding.
+
+ ``serde`` accepts a legacy ``{"__type": ..., "__var": ...}`` shape and
rewrites it
+ into the current one *inside* ``deserialize``. Anything inspecting the
payload before
+ that call therefore has to normalise it first, or the legacy spelling
carries no
+ ``__classname__`` at the moment it is looked at and slips past unexamined.
+ """
+ from airflow.sdk.serde import _convert, CLASSNAME, DATA
Review Comment:
Both deliberate, and you were right about the order — that unsorted line was
one of the two CI static-check failures (`I001`). Fixed.
The local imports are intentional: `encoders.py` keeps `from
airflow.sdk.serde import serialize` local in the mirror-image
`encode_deadline_alert` for the same reason, so core doesn't pull the SDK
serializer registry in at import time. Keeping them local is also what the
`check-sdk-imports-in-core` hook is steering toward — which was the *other* CI
failure: this file now needs 3 SDK imports against a recorded ceiling of 2, so
I've raised it to 3. The type-only `TYPE_CHECKING` import carries `# noqa:
SDK001` instead, since it creates no runtime coupling and shouldn't spend
budget that's meant to track exactly that. Happy to just record 4 instead if
you'd rather not be the first user of the noqa.
---
Drafted-by: Claude Opus 5; reviewed by @potiuk 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]
