-
Notifications
You must be signed in to change notification settings - Fork 16.3k
Improve xcom_pull to cover different scenarios for mapped tasks
#51568
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve xcom_pull to cover different scenarios for mapped tasks
#51568
Conversation
xcom_pull to reflect reality for mapped tasksxcom_pull to cover different scenarios for mapped tasks
Co-authored-by: Tzu-ping Chung <uranusjr@gmail.com>
|
Thanks for the review, merging it. |
|
Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions. |
|
Why are the return values of |
|
@sdg9670f Historical compat. Most of the time you shouldn't be using methods on |
closes: #50686
Problem
The expected behaviour from a downstream task pulling xcoms off of a mapped task would be to pull ALL the xcoms for that mapped task (all map indexes). Right now the problem we are suffering from is the way we treat defaults in our current logic.
Our logic is broken in a way that if map indexes arent specified, we function in a way that we pull from the corresponding map index of upstream task. This is because of the way we handle defaults as of now:
https://github.com/apache/airflow/blob/main/task-sdk/src/airflow/sdk/execution_time/task_runner.py#L349-L360
Scenarios that show how things work:
This is wrong. We should be pulling from all map indexes of the upstream task if not specified.
Approach
Leveraging: #50117 here. If you pass in the
start,end,stepas None -- the API is designed to return ALL the xcoms for the task, exactly what we want.So i am currently changing the logic to "if map_indexes aren't provided, fetch all the map_indexes available".
Testing
Test 1: Checking with DAG provided by @TJaniF
DAG:
Test 2: DAG reported by issue reporter
DAG:
Test 3: Created a comprehensive DAG to cover all use cases
This dag handles all possible scenarios:
Logs:
^ 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.