-
Notifications
You must be signed in to change notification settings - Fork 13.9k
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
Fix timeout when using XCom with KubernetesPodOperator #15388
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Daniel and I did a lot of diving into this to work out why it was 30 seconds to begin with, and my conclusion is that when this was ported from Python to Bash, it was converted from a try/except
to a trap
, but without the realisation that trap
will wait for the sleep to finish before it runs the interrupt command - meaning it will always wait up to 30 seconds to return. The Python version would not have had this issue, so that's why it had 30 seconds in there to start with.
I think this change looks good based on what I researched.
The PR is likely OK to be merged with just subset of tests for default Python and Database versions without running the full matrix of tests, because it does not modify the core of Airflow. If the committers decide that the full tests matrix is needed, they will add the label 'full tests needed'. Then you should rebase to the latest master or amend the last commit of the PR, and push it with --force-with-lease. |
19cef6d
to
e179b5c
Compare
Currently, the xcom sidecar container for the KubernetesPodOperator will sleep for 30 seconds before checking if the xcom has completed. This is far too long of a wait, as a 1 second wait will ensure that the process is not consistently blocked.
e179b5c
to
8b92b25
Compare
Currently, the xcom sidecar container for the KubernetesPodOperator will
sleep for 30 seconds before checking if the xcom has completed. This is
far too long of a wait, as a 1 second wait will ensure that the process
is not consistently blocked.
^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code change, 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 UPDATING.md.