Repository navigation
Downgrade "XCom not found" log to warning in Task SDK client - #73201
Closed
robertorobles wants to merge 1 commit into
Closed
robertorobles wants to merge 1 commit into
robertorobles wants to merge 1 commit into
Conversation
TaskInstance.xcom_pull() gracefully returns None when the requested XCom key doesn't exist (matching Airflow 2.x behavior), but the Task SDK's HTTP client logged this expected, handled condition at ERROR level. This produces noisy, misleading ERROR lines in task logs for a common and valid pattern (checking for an optional upstream XCom), which is confusing for monitoring/alerting setups that key off ERROR-level task logs. Related: apache#45341, apache#45344 (which introduced this behavior while fixing a task crash on missing XCom). Closes: apache#73175 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
robertorobles
requested review from
amoghrajesh,
ashb and
kaxil
as code owners
September 15, 2026 16:12
|
Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
|
Author
Author
|
Superseded by #73198. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: #73175
Description
TaskInstance.xcom_pull()from within a running task goes throughairflow.sdk.api.client.py::XComOperations.get()(andget_sequence_item()). When the requested key/task_id has no matching XCom, the API server returns a404, which is caught and handled gracefully: the call returnsNone, matching Airflow 2.x behavior, and no exception propagates to the task.Before returning, though, this was logged at
ERRORlevel:This means any task using the common, valid pattern of pulling an optional upstream XCom (e.g. with a
default, or just checking whether something was pushed) emits a task-logERROReven though nothing failed. This is confusing for monitoring/alerting setups that key off ERROR-level task logs, and misrepresents an expected, already-handled condition as an error.This behavior was introduced in #45344 (closing #45341), which fixed a real bug — the task crashing entirely on a missing XCom — by catching the 404 and returning
None. That PR's discussion focused on not crashing; the log level itself wasn't discussed.Change
Downgrade the two
"XCom not found"log.error(...)calls inXComOperations.get()andXComOperations.get_sequence_item()tolog.warning(...). No behavior change — the call still returnsNone/anErrorResponseas before, only the log level changes.Scope is intentionally limited to these two XCom call sites (as opposed to also touching the unrelated
"Asset not found"log in the same file), to keep this focused and easy to review.Are you willing to submit a PR?