MrDXY opened a new issue, #51821: URL: https://github.com/apache/airflow/issues/51821
### Apache Airflow version 3.0.2 ### If "Other Airflow 2 version" selected, which one? 2.10.2 ### What happened? ### Summary The behavior of `TaskInstance.xcom_pull()` when `task_ids=None` has changed between Airflow **2.10.2** and **3.0.2**, leading to potentially **unexpected results** and **backward compatibility issues**. https://github.com/apache/airflow/blob/79838baef32afab08816bba958b4c1622cf162d6/task-sdk/src/airflow/sdk/execution_time/task_runner.py#L302-L303 --- ### Behavior in Airflow 2.10.2 In 2.10.2, calling: ```python ti.xcom_pull(key="some_key") ``` would internally delegate to `_xcom_pull()` and **not apply any `task_ids` filter**—effectively pulling the XCom with the given `key` from **any available task**, often returning the latest match. This was useful for DAG authors who just wanted to pull a known `key` from anywhere upstream, especially when only one upstream task returned the value. https://github.com/apache/airflow/blob/35087d7d10714130cc3e9e9730e34b07fc56938d/airflow/models/taskinstance.py#L610-L617 --- ### Behavior in Airflow 3.0.2 In 3.0.2, the implementation changed, and now this call: ```python ti.xcom_pull(key="some_key") ``` defaults to: ```python task_ids = [self.task_id] ``` Which means it only pulls the XCom written by the **current task itself**, not from any upstream tasks. This is a **significant change in default behavior** and can silently break DAGs or plugins written for older versions. https://github.com/apache/airflow/blob/79838baef32afab08816bba958b4c1622cf162d6/task-sdk/src/airflow/sdk/execution_time/task_runner.py#L340-L342 --- ### Example Impact In 2.10.2: ```python # Pulls 'result' from any upstream task that pushed it ti.xcom_pull(key="result") ``` In 3.0.2: ```python # Only pulls 'result' from the current task (likely returns None) ti.xcom_pull(key="result") # Will NOT find upstream result unless task_ids is specified ``` ### What you think should happen instead? The default behavior should remain consistent across versions to avoid unexpected regressions. ### How to reproduce It's straightforward to reproduce the issue. Define a DAG with two tasks where TaskA runs before TaskB (TaskA >> TaskB), and then: Have TaskA push an XCom value with key="some_key" and value="some_value". In TaskB, call xcom_pull("some_key") without specifying task_ids. In Airflow **2.10.2**, this correctly retrieves "some_value" from TaskA. In Airflow **3.0.2**, the same call returns None, since it defaults to pulling from TaskB itself. ### Operating System Linux ### Versions of Apache Airflow Providers _No response_ ### Deployment Official Apache Airflow Helm Chart ### Deployment details _No response_ ### Anything else? _No response_ ### Are you willing to submit PR? - [x] Yes I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md) -- 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]
