uranusjr opened a new pull request, #76825: URL: https://github.com/apache/airflow/pull/76825
Currently, the Get XCom API with no map index always read map index -1. A mapped task has no -1 row, so pulling one without a map index returned null. This is useless, and I’m considering it a bug. From Execution API version 2027-02-28, the server resolves an omitted map index from the producing task's definition in its Dag: | Producing task | Map index | Result | |---|---|---| | Not mapped | omitted | Its value | | Mapped | omitted | All instances' values as a list | | Any | integer | That instance's value, or null if there is none (unchanged) | Older API versions keep reading -1. Python: - `XCom.get_one(map_index=None)` and `xcom_pull(map_indexes=None)` on a mapped task now return a list, matching what `xcom_pull` returns without `map_indexes`. - The client now sends an explicit `-1` instead of dropping it. - Resolving an XCom argument from an unmapped upstream passes `-1`, so the server doesn't need to look up the task's definition. Language SDKs: the supervisor protocol is unchanged, so the fix reaches Java, Go and TypeScript through the supervisor. Their docs now describe the result. Breaking change in TypeScript: `getXCom` now requires `taskId`, and `mapIndex` defaults to `null` instead of the running task's own map index, matching Java and Go. The Kubernetes mixed-language e2e Dag gains a mapped Python task, and its Go, Java and TypeScript tasks each check they read `[1, 2, 3]`. -- 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]
