You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 8bd103b
Browse filesBrowse the repository at this point in the historyBrowse files
Add a POST /xcoms/{dag_id}/{run_id}/{task_id}/keys execution API endpoint
XComIterable, the result of an iterated task, stores one XCom per iteration
under distinct keys (return_value_0, return_value_1, ...) of the same task
instance. The existing slice endpoint for a mapped task's XComs ranges over
map_index for a single key, the inverse shape, so iterating or slicing an
XComIterable cost one GET per value.
The new endpoint takes a list of keys and returns their values in that order,
None for a key without an XCom, filtered by map_index (-1 by default), in one
database query. Around it:
* XComKeysRequest body model, and an AddXComKeysEndpoint execution API version
change so older clients keep their contract.
* has_xcom_access reads the optional key from the request's path parameters,
so the endpoint needs no separate router or dependency.
* GetXComByKeys supervisor message, XComOperations.get_by_keys client method,
handle_get_xcom_by_keys handler registered with the task supervisor and the
DAG processor, an AddGetXComByKeys supervisor schema version entry and the
regenerated schema snapshot.
* BaseXCom.get_by_keys sends the message and deserializes the values, and
XComIterable iterates and slices through it: one request instead of one per
value. A single index stays one XCom read.
Stacked on the task iteration PR, which owns XComIterable; only this commit
belongs to the endpoint. Squashed from the earlier history of this branch and
re-based on that PR, with XComIterable's batched reads moved to its current
home in bases/xcom.py.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
0 commit comments