Repository navigation
Render XCom values on the API server without rebuilding objects - #74829
Conversation
`GET .../xcomEntries/{key}?deserialize=true` fell back to
`XComModel.deserialize_value()` for any `airflow.*` class, running full
serde in the API server only to turn the result back into a string.
`stringify()` now renders `airflow.*` classes from their serialized
fields without importing them, producing the same repr-style output for
attrs/dataclass types, so the fallback is removed from the XCom endpoint
and the `XComOperatorLink` extra-link lookup.
Generated-by: Claude Opus 5 following the guidelines at https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions
…splay Only asset definitions, which are attrs types, have serialized fields that mirror their repr. Other Airflow classes can define serialize() returning internal state that their repr never shows, e.g. the storage options kept by ObjectStoragePath. Show those by their path or URI only. Generated-by: Claude Opus 5 following the guidelines at https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions
|
@pierrejeambrun @ashb Could you take a look at this when you have a moment? It's targeted at 3.4.0 and needs a review to make the cut on 2026-10-19. CI is green. It goes together with #72718. |
There was a problem hiding this comment.
Looks good to me. stringify now renders airflow.* classes from their serialized fields without importing them, the tests compare against the real repr for assets, and nothing else imported StringifyNotSupportedError.Could use reviews from @pierrejeambrun @ashb before merging.
Backport successfully created: v3-4-testNote: As of Merging PRs targeted for Airflow 3.X In matter of doubt please ask in #release-management Slack channel.
|
2 participants
GET .../xcomEntries/{key}?deserialize=truerenders stored values withstringify(), but fell back toXComModel.deserialize_value()for anyairflow.*class. That fallback runs full serde in the API server just to turnthe result back into a string for the response. The API server only needs the
readable form, so it does not have to rebuild the objects at all. This follows
the "full serde shouldn't run on the API server" direction from the review
of #73625, and matches the scheduler-side change in #72718.
stringify()now rendersairflow.*classes from their serialized fields,without importing them. For attrs/dataclass types like
AssetandAssetAlias, the output is the samerepr-style text as before, e.g.AssetAlias(name='x', group='asset'). Nested non-Airflow classes keep theexisting
module.Class@version=N(...)form. Because nothing raisesStringifyNotSupportedErrorany more, the fallback is removed from the XComendpoint and the
XComOperatorLinkextra-link lookup.Response shapes and the OpenAPI schema are unchanged.
deserialize=falseandstringify=truebehave as before. The Execution API write path is untouched.Tests:
uv run pytestfor the XCom route tests (90 passed),test_stringify.py(53 passed),
test_operatorlink.py(2 passed),test_extra_links.py(28 passed) and
utils/test_json.py(11 passed)prek run --fileson the changed files: all hooks pass exceptGenerate the FastAPI API spec, which needs the Breeze CI image. The changedoes not touch any route signature or datamodel.
Was generative AI tooling used to co-author this PR?
Generated-by: Claude Opus 5 following the guidelines
{pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.