Fix custom xcom backend deserialize when BaseXCom.get_all is used #53814
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
closes: #53432
Problem
The
BaseXCom.get_all()method was directly calling deserialize() from the serialization module instead of using the overridable cls.deserialize_value() method. This broke custom XCom backends that rely on overridingdeserialize_value()to implement custom deserialization logic.Example of broken behavior:
Root Cause
The issue comes from inconsistent deserialization patterns:
cls.deserialize_value(msg)where msg is anXComResultwith a value attributedeserialize(msg.root)directly, wheremsg.rootis alist[JsonValue]The deserialize_value() method expects an object with a value attribute, but the sequence slice returns a flat list of serialized values.
_XComValueWrapperthat provides.valueas neededTesting
DAG:
Write a custom xcom backend:
Run breeze with:
Validate if the right one got loaded:
Run the dag:
Push task

Pull task

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named
{pr_number}.significant.rstor{issue_number}.significant.rst, in airflow-core/newsfragments.