Repository navigation
Support multiple_outputs in @task.bash - #71808
Merged
dheerajturaga merged 3 commits intoSep 1, 2026
Merged
Conversation
Miretpl
requested changes
Aug 25, 2026
Member
Author
|
@Miretpl , I have responded to your concerns. I have 2 more follow-up PRs once this merges.
I will add more context to the docs with those PRs as needed |
The BashOperator already unrolls a dict return value into one XCom per key, since multiple_outputs is a BaseOperator parameter honoured by the task runner. The @task.bash decorator warned that the option was unsupported and silently forced it off, so Dag authors could not name individual outputs from a Bash task even though the underlying operator supported it.
Airflow 2.11 bundles its own `@task.bash` decorator that ignores `multiple_outputs` and warns about it. The compatibility test suite imports `task` from `airflow.decorators` on Airflow 2, so the test exercises that bundled decorator rather than the provider's, and the new behaviour is not reachable there.
The advice was not specific to multiple XCom outputs — every Bash task logs its command output — and it read as though task logs offered no protection at all. Secrets registered with the masker are redacted in task logs, and the real gap for unregistered values is already covered in the security model docs, so restating it here was both misplaced and misleading.
dheerajturaga
force-pushed
the
bash-decorator-multiple-outputs
branch
from
September 1, 2026 16:21
10e8e5f to
839c791
Compare
Miretpl
approved these changes
Sep 1, 2026
Contributor
|
Feel free to mark me for the review of followup. |
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.
BashOperatoralready unrolls a dict return value into one XCom per key —multiple_outputsis aBaseOperatorparameter and the Task SDK runner honours itregardless of which operator produced the value. Pairing it with
output_processorworks on
BashOperatortoday:The
@task.bashdecorator, however, warned that the option was unsupported andsilently forced it off, so Dag authors could not name individual outputs from a Bash
task even though the operator it wraps supported it. This drops the warning and lets
the value through, which also makes
@task.bashconsistent with the other decoratorsin the provider (
@task.virtualenv,@task.short_circuit, …), all of which passmultiple_outputsthrough.Docs gained a "Multiple XCom outputs" section — the existing "Output processor"
section never mentioned
multiple_outputs, which made the capability easy to miss.Both example Dags gained a producer/consumer task pair so the documented snippets come
from code that CI parses.
The docs are deliberately explicit about the constraints, since only the last line of
the merged stdout/stderr stream is captured: a trailing blank
echoor a subcommandwriting to
stderrlast will overwrite the dict, the JSON must be single-line, andevery emitted line reaches the task log.
Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 5) following the guidelines