[anzinmhd]

Saving an XCom through the UI can unintentionally change its stored type. This PR preserves the stored value’s type when loading the edit form and retains its JSON representation when saving.

The bug was reproduced on main and independently confirmed in the official apache/airflow:3.4.0b2 image.

Problem

For an XCom containing the string "123", opening Edit and clicking Save without changing anything replaces it with the number 123.

The problem is not limited to unchanged saves. Because the editor loses the distinction between a string and another JSON type, editing a string to another JSON-looking value can also result in an unintended type conversion. This broader risk follows from the same conversion path; intentional-edit scenarios have not been separately verified.

There are two opportunities for unintended conversion:

1. The edit form requests deserialize=true. The API can parse a stored JSON-looking string into another type before returning it to the editor.
2. The form populates the JSON editor with unquoted string content, then calls JSON.parse() when saving. Strings containing JSON literals can consequently become numbers, booleans, objects, arrays, or null.

An unchanged save provides a minimal reproduction: it demonstrates that the stored type changes without the user requesting any modification.

Fix

Load the edit form from the stored value using deserialize=false and stringify=false, then populate the JSON editor with JSON.stringify().

These changes address both conversion points:

• The read request preserves the stored value’s type.
• JSON formatting preserves string quotation marks and escaping, allowing the existing save parser to reconstruct the original value.

For example:

Stored value	Editor content	After an unchanged save
String "123"	"123" with quotation marks	String "123"
Number 123	123 without quotation marks	Number 123

The editor now makes the type distinction explicit. Users can retain quotation marks when editing a string or deliberately remove them to change its type.

The backend API and display-only XCom view are unchanged.

Steps to reproduce

1. Create a manually triggered Dag with a TaskFlow task that returns the string "123".
2. Trigger the Dag and wait for the task to succeed.
3. Open the task’s XCom tab and locate return_value.
4. Open the individual XCom API URL with deserialize=false&stringify=false.
5. Confirm that the response contains "value":"123".
6. Return to the UI, open Edit XCom, and click Save without changing anything.
7. Reload the same API URL.

Before: The response contains "value":123. Saving unchanged has replaced the stored string with a number.

After: The response still contains "value":"123". The stored string is preserved.

Using the same raw-response parameters before and after distinguishes a stored-value change from display formatting or response deserialization.

Version verification

• Main: Reproduced the bug and manually verified the fix.
• 3.4.0b2: Independently reproduced the bug using the official Docker image in an isolated environment. Saving unchanged converted the stored string "123" into the number 123.

The beta verification confirms that the bug affects 3.4.0b2; the fix itself was verified on the local development checkout.

Tests and validation

Added eight regression cases covering:

• Numeric-looking strings
• Boolean-looking strings
• Null-looking strings
• Object-looking strings
• Array-looking strings
• Strings containing quotation marks
• Empty strings
• Multiline strings

The tests verify the read query parameters, the JSON editor content, and the value sent in the update request after saving without edits.

Validation completed:

• All eight new regression cases fail without the production fix.
• All 22 tests across the three XCom test files pass with the fix.
• Targeted ESLint and Prettier checks pass.
• TypeScript checking passes.
• Manually verified that an unchanged save preserves the string in the API response using deserialize=false&stringify=false.

The automated regression cases and manual reproduction specifically cover unchanged saves.

Before

Opening Edit and saving without changes converts the stored string "123" into the number 123.

before.mov

After

The editor retains the string’s JSON quotation marks, and saving without changes preserves "value":"123" in the raw API response.

after.mov

---

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

• Yes — Codex (GPT-6)

[github-actions]

Backport successfully created: v3-4-test

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-4-test