dheerajturaga commented on code in PR #71808:
URL: https://github.com/apache/airflow/pull/71808#discussion_r3889985401
##########
providers/standard/docs/operators/bash.rst:
##########
@@ -226,6 +226,58 @@ Here's how you can use the result_processor with the
BashOperator:
)
+Multiple XCom outputs
Review Comment:
Agreed on both counts, and thanks for checking — you're right that the
coverage is thin. What exists today is
[`core-concepts/xcoms.rst:74-93`](https://github.com/apache/airflow/blob/main/airflow-core/docs/core-concepts/xcoms.rst#L74-L93),
which documents it for plain `@task` only, and
[`providers/docker/docs/decorators/docker.rst:33-35`](https://github.com/apache/airflow/blob/main/providers/docker/docs/decorators/docker.rst#L33-L35),
which is a one-line parameter entry. Grepping the provider docs, those two
plus this page are the only places `multiple_outputs` is mentioned at all — so
every other operator and decorator that supports it is undocumented.
Happy to take that as a follow-up rather than growing this PR. I'd keep this
one scoped to `@task.bash`, since the Bash case needs the last-line caveats
that don't apply anywhere else.
One piece of history worth recording in that follow-up, because it explains
*why* the gap exists — the `@task.bash` warning was correct when it was
written, and a later refactor invalidated it without anyone noticing:
* #30176 introduced `@task.bash` on 2023-12-19 with the warning built in
from the first commit. At that point `multiple_outputs` was purely a
decorator-layer feature, unrolled in `DecoratedOperator._handle_output`, which
acted on the value returned by the **decorated callable**. For `@task.bash`
that value is the bash command string — the decorator raises `TypeError` if it
isn't one — so `_handle_output` could only ever have hit its `else` branch and
raised *"Returned output was type `<class 'str'>` expected dictionary for
multiple_outputs"*. Refusing it was the right call.
* #37297 then moved the unrolling out of the decorator and into
`BaseOperator` / `TaskInstance` on 2024-02-12, ~2 months later, so it began
acting on the **operator's** return value instead.
* #40843 added `output_processor` to `BashOperator` on 2024-08-05, which is
what makes that return value a dict.
Neither of the latter two revisited the decorator's guard, so it survived ~2
years describing a constraint that had stopped being true. That's the same
class of drift as the missing docs you spotted — which is an argument for
documenting `multiple_outputs` per-operator rather than only in core, where a
change to the core mechanism can silently invalidate what a provider says about
it.
---
Drafted-by: Claude Code (Opus 5); reviewed by @dheerajturaga before posting
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
