Repository navigation
Fix KubernetesPodOperator XCom loss when container_logs is a string - #72502
Merged
potiuk merged 1 commit intoSep 8, 2026
Merged
Conversation
When container_logs is a single container name, the check that decides whether the base container still needs to be awaited used `in` on a string, which is a substring match. Any name containing the base container name (a typo like "base2", or a sidecar like "base-metrics") made the operator believe the base container's logs were being followed and skip the explicit wait. XCom extraction then ran while the base container was still running, read an empty result, tore down the sidecar, and the task succeeded with a None XCom.
henry3260
requested review from
hussein-awala,
jedcunningham and
jscheffl
as code owners
September 4, 2026 08:24
boring-cyborg
Bot
added
area:providers
provider:cncf-kubernetes
henry3260
added
the
ready for maintainer review
potiuk
approved these changes
Sep 8, 2026
imrichardwu
pushed a commit
to imrichardwu/airflow
that referenced
this pull request
Sep 11, 2026
…pache#72502) When container_logs is a single container name, the check that decides whether the base container still needs to be awaited used `in` on a string, which is a substring match. Any name containing the base container name (a typo like "base2", or a sidecar like "base-metrics") made the operator believe the base container's logs were being followed and skip the explicit wait. XCom extraction then ran while the base container was still running, read an empty result, tore down the sidecar, and the task succeeded with a None XCom.
regarmukesh3g
pushed a commit
to regarmukesh3g/airflow
that referenced
this pull request
Sep 27, 2026
…pache#72502) When container_logs is a single container name, the check that decides whether the base container still needs to be awaited used `in` on a string, which is a substring match. Any name containing the base container name (a typo like "base2", or a sidecar like "base-metrics") made the operator believe the base container's logs were being followed and skip the explicit wait. XCom extraction then ran while the base container was still running, read an empty result, tore down the sidecar, and the task succeeded with a None XCom.
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
2 participants
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.
Why
KubernetesPodOperator.await_pod_completiondecides whether it still has to wait for the base container withself.base_container_name not in self.container_logs.container_logsaccepts a single container name as a plain string, and that is also the default ("base"), so for string values this is a substring check rather than a membership check. Any name that merely contains the base container name, such as a typo like"base2"or a sidecar named"base-metrics", makes the operator believe the base container's logs are being followed and skipawait_container_completion.With
do_xcom_push=Truethe operator then execs into the XCom sidecar while the base container is still running, reads an emptyreturn.json, tears the sidecar down, and the task succeeds with aNoneXCom. Nothing is logged as an error, so downstream tasks silently receive wrong data.What
providers/cncf/kubernetes/src/airflow/providers/cncf/kubernetes/operators/pod.py: normalise a stringcontainer_logsinto a single-element list before the membership check inawait_pod_completion, so the base container is awaited whenever its logs are not actually being followed. Behaviour forTrueand list values is unchanged.Was generative AI tooling used to co-author this PR?