dheerajturaga opened a new pull request, #71808:
URL: https://github.com/apache/airflow/pull/71808
`BashOperator` already unrolls a dict return value into one XCom per key —
`multiple_outputs` is a `BaseOperator` parameter and the Task SDK runner
honours it
regardless of which operator produced the value. Pairing it with
`output_processor`
works on `BashOperator` today:
```python
BashOperator(
task_id="emit",
bash_command="""echo '{"rows": 42, "uri": "s3://bucket/out"}'""",
multiple_outputs=True,
output_processor=json.loads,
)
# pushes: rows=42, uri="s3://bucket/out", return_value={"rows": 42, "uri":
...}
```
The `@task.bash` decorator, however, 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 operator it wraps supported it. This drops the warning
and lets
the value through, which also makes `@task.bash` consistent with the other
decorators
in the provider (`@task.virtualenv`, `@task.short_circuit`, …), all of which
pass
`multiple_outputs` through.
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 `echo` or a
subcommand
writing to `stderr` last will overwrite the dict, the JSON must be
single-line, and
every emitted line reaches the task log. A follow-up PR is planned to add a
file-based side channel (`AIRFLOW_XCOM_DIR`) that avoids these constraints
entirely.
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes — Claude Code (Opus 5)
Generated-by: Claude Code (Opus 5) following [the
guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions)
--
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]
