The GitHub Actions job "uv in /. for lxml - Update #1378706624" on 
airflow.git/main has failed.
Run started by GitHub user dependabot[bot] (triggered by dependabot[bot]).

Head commit for run:
ca05a56f6a1d92de8033254d0e65460a01af9606 / Paul Mathew <[email protected]>
Fix multiple_outputs no-op on deferrable KubernetesPodOperator (#67226)

* Fix multiple_outputs no-op on deferrable KubernetesPodOperator

KubernetesPodOperator(do_xcom_push=True, multiple_outputs=True,
deferrable=True) silently failed to fan out the sidecar's return.json dict
into per-key XComs — only `return_value` was published. Downstream tasks
subscripting a key (operator.output["foo"] resolving to xcom_pull(key="foo"))
got None at runtime with no error.

Root cause: trigger_reentry pushed return_value manually inside a finally
block and never returned the value to the task runner, so the runner's
_push_xcom_if_needed (the code that honors multiple_outputs and fans the
dict out) was bypassed. The sync execute_sync path already returns the
result for the runner to handle (pod.py:760); this aligns trigger_reentry
with that same contract.

The failure-path manual push is preserved by moving it inside the
event["status"] != "success" branch above the raise — partial sidecar
output is still surfaced in XCom when the pod fails, and the behavior is
now strictly better: the push happens even when the subsequent _clean
call raises (previously the in-finally push was unreachable in that case).

Fixes #67224

Co-authored-by: Cursor <[email protected]>

* Trigger CI rerun after upload-artifact 403 flake

Co-authored-by: Cursor <[email protected]>

* Apply multiple_outputs fan-out to KPO failure paths consistently

Address review on #67226: the previous commit fixed the success path on
deferrable KPO but left both sync and async failure paths still pushing
only ``return_value``, silently dropping ``multiple_outputs`` fan-out.

Add an operator-local ``_push_xcom_with_fan_out`` helper that mirrors the
task runner's ``_push_xcom_if_needed`` and call it from both failure-path
manual pushes (sync ``post_complete_action`` and async ``trigger_reentry``).
All four code paths — sync success/failure, async success/failure — now
honour ``multiple_outputs`` consistently.

Promoting ``_push_xcom_if_needed`` to a public task-SDK helper would let
other operators that manually push XCom on failure paths reuse the same
logic and would be a cleaner long-term fix. Left as a follow-up since
manual ``XCOM_RETURN_KEY`` pushes are essentially KPO-specific today
(grep across all providers turns up only one other operator) and the
local helper keeps this PR's blast radius matched to its scope.

Tests:
- New ``test_xcom_push_failed_pod_fans_out_for_multiple_outputs`` covers
  the sync failure path.
- New ``test_async_trigger_reentry_failure_fans_out_for_multiple_outputs``
  covers the async failure path.

Also incorporate review nits: drop unnecessary comments, switch ``is`` to
``==`` for dict equality checks, and trim the historical context from the
new test docstring (moved to the PR description).

Co-authored-by: Cursor <[email protected]>

* Use explicit ``is None`` guard in ``_push_xcom_with_fan_out``

Address review from @jscheffl on #67226: the previous ``if not value:``
guard would skip the manual XCom push for any falsy-but-non-None payload
(``False``, ``0``, ``""``, ``[]``, ``{}``) — all of which are legitimate
sidecar outputs that downstream tasks may rely on. Switch to ``is None``
so only the "nothing extracted" case is skipped, matching the task
runner's ``_push_xcom_if_needed`` semantics (which also guards on
``xcom_value is None``).

Also fix D213 docstring style flagged by ruff (multi-line summary should
start on the second line).

Co-authored-by: Cursor <[email protected]>

---------

Co-authored-by: Cursor <[email protected]>

Report URL: https://github.com/apache/airflow/actions/runs/26255596946

With regards,
GitHub Actions via GitBox


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to