Apply reserved-key check to XCom update payload by potiuk · Pull Request #65915 · apache/airflow

potiuk · 2026-04-27T01:27:44Z

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved
serialization keys (__classname__, __type, __var, __data__, …) via a
field_validator that walks the value recursively. XComUpdateBody (PATCH
/xcomEntries/{key}) was missing the same validator, so a payload that POST
correctly rejects with 422 was accepted on PATCH and stored as-is.

This change extracts the recursive walker to a module-level
_check_forbidden_xcom_keys helper and has both XComCreateBody and
XComUpdateBody delegate to it, so create and update apply the same
payload-key check from a single source. A parametrized test mirroring the
existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

The three regenerated files (_private_ui.yaml, schemas.gen.ts,
types.gen.ts) are pre-commit catch-up for an unrelated ExtraMenuItem
description that had drifted on main; they aren't part of the substantive
change.

^ Add meaningful description above

New TestPatchXComEntry::test_patch_xcom_entry_blocks_forbidden_keys covers the three reserved-key shapes and asserts HTTP 422 with "reserved serialization keys" in the detail.
Existing TestCreateXComEntry::test_create_xcom_entry_blocks_forbidden_keys still passes — create-side error message is byte-identical, behaviour preserved.
Existing TestPatchXComEntry cases all pass (valid update, complex object, integer, list, not-found, slash-key, int-type-preservation).
prek run --files <changed files> clean and idempotent.

Was generative AI tooling used to co-author this PR?

Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines at
https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

potiuk · 2026-04-30T18:06:26Z

Chance for a review :)

github-actions · 2026-05-07T17:51:22Z

Hi maintainer, this PR was merged without a milestone set.
We've automatically set the milestone to Airflow 3.2.2 based on: backport label targeting v3-2-test
If this milestone is not correct, please update it to the appropriate milestone.

This comment was generated by Milestone Tag Assistant.

github-actions · 2026-05-07T17:51:29Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker c173489 v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path. (cherry picked from commit c173489)

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path. (cherry picked from commit c173489) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

potiuk · 2026-04-27T01:27:44Z

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved
serialization keys (__classname__, __type, __var, __data__, …) via a
field_validator that walks the value recursively. XComUpdateBody (PATCH
/xcomEntries/{key}) was missing the same validator, so a payload that POST
correctly rejects with 422 was accepted on PATCH and stored as-is.

This change extracts the recursive walker to a module-level
_check_forbidden_xcom_keys helper and has both XComCreateBody and
XComUpdateBody delegate to it, so create and update apply the same
payload-key check from a single source. A parametrized test mirroring the
existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

The three regenerated files (_private_ui.yaml, schemas.gen.ts,
types.gen.ts) are pre-commit catch-up for an unrelated ExtraMenuItem
description that had drifted on main; they aren't part of the substantive
change.

^ Add meaningful description above

New TestPatchXComEntry::test_patch_xcom_entry_blocks_forbidden_keys covers the three reserved-key shapes and asserts HTTP 422 with "reserved serialization keys" in the detail.
Existing TestCreateXComEntry::test_create_xcom_entry_blocks_forbidden_keys still passes — create-side error message is byte-identical, behaviour preserved.
Existing TestPatchXComEntry cases all pass (valid update, complex object, integer, list, not-found, slash-key, int-type-preservation).
prek run --files <changed files> clean and idempotent.

Was generative AI tooling used to co-author this PR?

Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines at
https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

potiuk · 2026-04-30T18:06:26Z

Chance for a review :)

github-actions · 2026-05-07T17:51:22Z

Hi maintainer, this PR was merged without a milestone set.
We've automatically set the milestone to Airflow 3.2.2 based on: backport label targeting v3-2-test
If this milestone is not correct, please update it to the appropriate milestone.

This comment was generated by Milestone Tag Assistant.

github-actions · 2026-05-07T17:51:29Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker c173489 v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path. (cherry picked from commit c173489)

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path. (cherry picked from commit c173489) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

potiuk · 2026-04-27T01:27:44Z

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved
serialization keys (__classname__, __type, __var, __data__, …) via a
field_validator that walks the value recursively. XComUpdateBody (PATCH
/xcomEntries/{key}) was missing the same validator, so a payload that POST
correctly rejects with 422 was accepted on PATCH and stored as-is.

This change extracts the recursive walker to a module-level
_check_forbidden_xcom_keys helper and has both XComCreateBody and
XComUpdateBody delegate to it, so create and update apply the same
payload-key check from a single source. A parametrized test mirroring the
existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

The three regenerated files (_private_ui.yaml, schemas.gen.ts,
types.gen.ts) are pre-commit catch-up for an unrelated ExtraMenuItem
description that had drifted on main; they aren't part of the substantive
change.

^ Add meaningful description above

New TestPatchXComEntry::test_patch_xcom_entry_blocks_forbidden_keys covers the three reserved-key shapes and asserts HTTP 422 with "reserved serialization keys" in the detail.
Existing TestCreateXComEntry::test_create_xcom_entry_blocks_forbidden_keys still passes — create-side error message is byte-identical, behaviour preserved.
Existing TestPatchXComEntry cases all pass (valid update, complex object, integer, list, not-found, slash-key, int-type-preservation).
prek run --files <changed files> clean and idempotent.

Was generative AI tooling used to co-author this PR?

Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines at
https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

potiuk · 2026-04-30T18:06:26Z

Chance for a review :)

github-actions · 2026-05-07T17:51:22Z

Hi maintainer, this PR was merged without a milestone set.
We've automatically set the milestone to Airflow 3.2.2 based on: backport label targeting v3-2-test
If this milestone is not correct, please update it to the appropriate milestone.

This comment was generated by Milestone Tag Assistant.

github-actions · 2026-05-07T17:51:29Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker c173489 v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path. (cherry picked from commit c173489)

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path. (cherry picked from commit c173489) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

potiuk · 2026-04-27T01:27:44Z

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved
serialization keys (__classname__, __type, __var, __data__, …) via a
field_validator that walks the value recursively. XComUpdateBody (PATCH
/xcomEntries/{key}) was missing the same validator, so a payload that POST
correctly rejects with 422 was accepted on PATCH and stored as-is.

This change extracts the recursive walker to a module-level
_check_forbidden_xcom_keys helper and has both XComCreateBody and
XComUpdateBody delegate to it, so create and update apply the same
payload-key check from a single source. A parametrized test mirroring the
existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

The three regenerated files (_private_ui.yaml, schemas.gen.ts,
types.gen.ts) are pre-commit catch-up for an unrelated ExtraMenuItem
description that had drifted on main; they aren't part of the substantive
change.

^ Add meaningful description above

New TestPatchXComEntry::test_patch_xcom_entry_blocks_forbidden_keys covers the three reserved-key shapes and asserts HTTP 422 with "reserved serialization keys" in the detail.
Existing TestCreateXComEntry::test_create_xcom_entry_blocks_forbidden_keys still passes — create-side error message is byte-identical, behaviour preserved.
Existing TestPatchXComEntry cases all pass (valid update, complex object, integer, list, not-found, slash-key, int-type-preservation).
prek run --files <changed files> clean and idempotent.

Was generative AI tooling used to co-author this PR?

Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines at
https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

potiuk · 2026-04-30T18:06:26Z

Chance for a review :)

github-actions · 2026-05-07T17:51:22Z

Hi maintainer, this PR was merged without a milestone set.
We've automatically set the milestone to Airflow 3.2.2 based on: backport label targeting v3-2-test
If this milestone is not correct, please update it to the appropriate milestone.

This comment was generated by Milestone Tag Assistant.

github-actions · 2026-05-07T17:51:29Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker c173489 v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path. (cherry picked from commit c173489)

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path. (cherry picked from commit c173489) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

potiuk · 2026-04-27T01:27:44Z

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved
serialization keys (__classname__, __type, __var, __data__, …) via a
field_validator that walks the value recursively. XComUpdateBody (PATCH
/xcomEntries/{key}) was missing the same validator, so a payload that POST
correctly rejects with 422 was accepted on PATCH and stored as-is.

This change extracts the recursive walker to a module-level
_check_forbidden_xcom_keys helper and has both XComCreateBody and
XComUpdateBody delegate to it, so create and update apply the same
payload-key check from a single source. A parametrized test mirroring the
existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

The three regenerated files (_private_ui.yaml, schemas.gen.ts,
types.gen.ts) are pre-commit catch-up for an unrelated ExtraMenuItem
description that had drifted on main; they aren't part of the substantive
change.

^ Add meaningful description above

New TestPatchXComEntry::test_patch_xcom_entry_blocks_forbidden_keys covers the three reserved-key shapes and asserts HTTP 422 with "reserved serialization keys" in the detail.
Existing TestCreateXComEntry::test_create_xcom_entry_blocks_forbidden_keys still passes — create-side error message is byte-identical, behaviour preserved.
Existing TestPatchXComEntry cases all pass (valid update, complex object, integer, list, not-found, slash-key, int-type-preservation).
prek run --files <changed files> clean and idempotent.

Was generative AI tooling used to co-author this PR?

Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines at
https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

potiuk · 2026-04-30T18:06:26Z

Chance for a review :)

github-actions · 2026-05-07T17:51:22Z

Hi maintainer, this PR was merged without a milestone set.
We've automatically set the milestone to Airflow 3.2.2 based on: backport label targeting v3-2-test
If this milestone is not correct, please update it to the appropriate milestone.

This comment was generated by Milestone Tag Assistant.

github-actions · 2026-05-07T17:51:29Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker c173489 v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path. (cherry picked from commit c173489)

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path. (cherry picked from commit c173489) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

potiuk · 2026-04-27T01:27:44Z

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved
serialization keys (__classname__, __type, __var, __data__, …) via a
field_validator that walks the value recursively. XComUpdateBody (PATCH
/xcomEntries/{key}) was missing the same validator, so a payload that POST
correctly rejects with 422 was accepted on PATCH and stored as-is.

This change extracts the recursive walker to a module-level
_check_forbidden_xcom_keys helper and has both XComCreateBody and
XComUpdateBody delegate to it, so create and update apply the same
payload-key check from a single source. A parametrized test mirroring the
existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

The three regenerated files (_private_ui.yaml, schemas.gen.ts,
types.gen.ts) are pre-commit catch-up for an unrelated ExtraMenuItem
description that had drifted on main; they aren't part of the substantive
change.

^ Add meaningful description above

New TestPatchXComEntry::test_patch_xcom_entry_blocks_forbidden_keys covers the three reserved-key shapes and asserts HTTP 422 with "reserved serialization keys" in the detail.
Existing TestCreateXComEntry::test_create_xcom_entry_blocks_forbidden_keys still passes — create-side error message is byte-identical, behaviour preserved.
Existing TestPatchXComEntry cases all pass (valid update, complex object, integer, list, not-found, slash-key, int-type-preservation).
prek run --files <changed files> clean and idempotent.

Was generative AI tooling used to co-author this PR?

Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines at
https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

potiuk · 2026-04-30T18:06:26Z

Chance for a review :)

github-actions · 2026-05-07T17:51:22Z

Hi maintainer, this PR was merged without a milestone set.
We've automatically set the milestone to Airflow 3.2.2 based on: backport label targeting v3-2-test
If this milestone is not correct, please update it to the appropriate milestone.

This comment was generated by Milestone Tag Assistant.

github-actions · 2026-05-07T17:51:29Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker c173489 v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path. (cherry picked from commit c173489)

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path. (cherry picked from commit c173489) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

potiuk · 2026-04-27T01:27:44Z

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved
serialization keys (__classname__, __type, __var, __data__, …) via a
field_validator that walks the value recursively. XComUpdateBody (PATCH
/xcomEntries/{key}) was missing the same validator, so a payload that POST
correctly rejects with 422 was accepted on PATCH and stored as-is.

This change extracts the recursive walker to a module-level
_check_forbidden_xcom_keys helper and has both XComCreateBody and
XComUpdateBody delegate to it, so create and update apply the same
payload-key check from a single source. A parametrized test mirroring the
existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

The three regenerated files (_private_ui.yaml, schemas.gen.ts,
types.gen.ts) are pre-commit catch-up for an unrelated ExtraMenuItem
description that had drifted on main; they aren't part of the substantive
change.

^ Add meaningful description above

New TestPatchXComEntry::test_patch_xcom_entry_blocks_forbidden_keys covers the three reserved-key shapes and asserts HTTP 422 with "reserved serialization keys" in the detail.
Existing TestCreateXComEntry::test_create_xcom_entry_blocks_forbidden_keys still passes — create-side error message is byte-identical, behaviour preserved.
Existing TestPatchXComEntry cases all pass (valid update, complex object, integer, list, not-found, slash-key, int-type-preservation).
prek run --files <changed files> clean and idempotent.

Was generative AI tooling used to co-author this PR?

Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines at
https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

potiuk · 2026-04-30T18:06:26Z

Chance for a review :)

github-actions · 2026-05-07T17:51:22Z

Hi maintainer, this PR was merged without a milestone set.
We've automatically set the milestone to Airflow 3.2.2 based on: backport label targeting v3-2-test
If this milestone is not correct, please update it to the appropriate milestone.

This comment was generated by Milestone Tag Assistant.

github-actions · 2026-05-07T17:51:29Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker c173489 v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path. (cherry picked from commit c173489)

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path. (cherry picked from commit c173489) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

potiuk · 2026-04-27T01:27:44Z

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved
serialization keys (__classname__, __type, __var, __data__, …) via a
field_validator that walks the value recursively. XComUpdateBody (PATCH
/xcomEntries/{key}) was missing the same validator, so a payload that POST
correctly rejects with 422 was accepted on PATCH and stored as-is.

This change extracts the recursive walker to a module-level
_check_forbidden_xcom_keys helper and has both XComCreateBody and
XComUpdateBody delegate to it, so create and update apply the same
payload-key check from a single source. A parametrized test mirroring the
existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

The three regenerated files (_private_ui.yaml, schemas.gen.ts,
types.gen.ts) are pre-commit catch-up for an unrelated ExtraMenuItem
description that had drifted on main; they aren't part of the substantive
change.

^ Add meaningful description above

New TestPatchXComEntry::test_patch_xcom_entry_blocks_forbidden_keys covers the three reserved-key shapes and asserts HTTP 422 with "reserved serialization keys" in the detail.
Existing TestCreateXComEntry::test_create_xcom_entry_blocks_forbidden_keys still passes — create-side error message is byte-identical, behaviour preserved.
Existing TestPatchXComEntry cases all pass (valid update, complex object, integer, list, not-found, slash-key, int-type-preservation).
prek run --files <changed files> clean and idempotent.

Was generative AI tooling used to co-author this PR?

Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines at
https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

potiuk · 2026-04-30T18:06:26Z

Chance for a review :)

github-actions · 2026-05-07T17:51:22Z

Hi maintainer, this PR was merged without a milestone set.
We've automatically set the milestone to Airflow 3.2.2 based on: backport label targeting v3-2-test
If this milestone is not correct, please update it to the appropriate milestone.

This comment was generated by Milestone Tag Assistant.

github-actions · 2026-05-07T17:51:29Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker c173489 v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path.

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path. (cherry picked from commit c173489)

XComCreateBody (POST /xcomEntries) rejects payloads containing reserved serialization keys (__classname__, __type, __var, __data__, …) via a field_validator that walks the value recursively. XComUpdateBody (PATCH /xcomEntries/{key}) was missing the same validator, so a payload that POST correctly rejects with 422 was accepted on PATCH and stored as-is. Extracts the recursive walker to a module-level _check_forbidden_xcom_keys helper and has both XComCreateBody and XComUpdateBody delegate to it, so create and update apply the same payload-key check from a single source. A parametrized test mirroring the existing test_create_xcom_entry_blocks_forbidden_keys covers the PATCH path. (cherry picked from commit c173489) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

potiuk requested review from bbovenzi, bugraoz93, choo121600, ephraimbuddy, guan404ming, jason810496, pierrejeambrun, rawwar, ryanahamilton, shubhamraj-git and vatsrahul1001 as code owners April 27, 2026 01:27

boring-cyborgBot added area:API Airflow's REST/HTTP API area:UI Related to UI/UX. For Frontend Developers. labels Apr 27, 2026

potiuk added the backport-to-v3-2-test label Apr 27, 2026

bbovenzi reviewed Apr 27, 2026
View reviewed changes

Comment threadairflow-core/src/airflow/api_fastapi/core_api/openapi/_private_ui.yaml

potiuk commented Apr 27, 2026
View reviewed changes

Comment threadairflow-core/src/airflow/api_fastapi/core_api/openapi/_private_ui.yaml

potiuk force-pushed the xcom-update-payload-reserved-key-check branch from 6ac254a to e23a515Compare April 27, 2026 16:00

potiuk force-pushed the xcom-update-payload-reserved-key-check branch from e23a515 to cdf529dCompare April 27, 2026 21:37

bbovenzi approved these changes May 7, 2026
View reviewed changes

bbovenzi merged commit c173489 into apache:mainMay 7, 2026
140 checks passed

github-actionsBot added this to the Airflow 3.2.2 milestone May 7, 2026

vatsrahul1001 mentioned this pull request May 14, 2026
[v3-2-test] Apply reserved-key check to XCom update payload (#65915) #66913
Merged
1 task

vatsrahul1001 mentioned this pull request May 21, 2026
Status of testing of Apache Airflow 3.2.2rc3 #67282
Closed

nixpkgs-security-trackerBot mentioned this pull request Jun 2, 2026
Apache Airflow: Authenticated RCE via XCom PATCH endpoint — XComUpdateBody missing FORBIDDEN_XCOM_KEYS validator NixOS/nixpkgs#527027
Closed