Uh oh!
There was an error while loading. Please reload this page.
Support dynamic task mapping on stub tasks - #70570
Draft
jason810496 wants to merge 1 commit into
Draft
Conversation
This was referenced Jul 28, 2026
This was referenced Aug 4, 2026
1 task
Restore the mapped (.expand()) stub arg-binding support split out of the unmapped PR: the Dag serializer captures per-parameter metadata (declaration order, defaults, value schemas) from the stub signature via the get_mapped_serialized_fields hook, ti_run derives per-map-index bindings from it with the map-index decomposition on SchedulerDictOfListsExpandInput, and XComArgBinding regains the map_index/element_index delivery fields across the task-sdk and ts-sdk generated models.
jason810496force-pushed
the
feature/lang-sdk/taskflow-stub-dag-mapped
branch
from
August 12, 2026 08:52
2c949d8 to
b786830Compare91 tasks
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 freeto 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.
related: lifts the
.expand()/.partial()restriction Support TaskFlow call syntax on stub tasks for the Lang SDK #69757 declared out of scope; the Go SDK runtime that consumes this is the stacked follow-up.Why
#69757 ships stub TaskFlow arg-binding but rejects
.expand()on a stub at parse time. This PR restores that scope: a@task.stubcan be dynamically task-mapped, and every map index gets its own arg-binding spec so the foreign runtime receives its element instead of the aggregated output.Supported dynamic-mapping forms
A mapped
@task.stubproduces one arg-binding per map index, always in the stub's signature declaration order (not call-site order). Each parameter resolves as one of:Expanded arguments —
.expand(param=…), value differs per index:transform.expand(country=["uk", "fr", "de"])literal, element resolved server-side (list → element; dict →[key, value]per item)transform.expand(extracted=extract())xcom+element_index=i(pull the single row, take elementi)transform.expand(extracted=seed.expand(n=[1, 2]))xcom+map_index=i(pull upstream rowidirectly)Multiple expanded arguments — cross product:
.expand(a=…, b=…)combine.expand(a=["x", "y"], b=[1, 2, 3])→ 6 instancesPartial arguments —
.partial(param=…), constant across every index:transform.partial(country="uk").expand(…)literal(same value every index)transform.partial(extracted=extract()).expand(…)xcom, whole return value (no sub-index)Defaulted arguments:
retries: int = 3left unpassedliteral+from_default: trueOne DAG exercising every form at once:
Rejected loudly (parse-time in the provider; re-checked server-side for Dags from other provider versions):
.expand_kwargs(); apartial()kwarg over a mapped upstream's aggregated output (would bind the nonexistentmap_index=-1row);.map()/.zip()/concator custom-key XCom; non-JSON literals; a mapped stub TI still atmap_index=-1. A mapped stub in an older-provider Dag (no captured metadata) delivers no bindings and keeps the legacy ignored-args behavior.How
_StubOperatorcaptures per-parameter metadata (declaration order, defaults, value schemas) via a new optionalget_mapped_serialized_fieldsoperator hook. The core serializer calls it at the single point whereoperator_class/python_callableare still the real objects — everything the server cannot recover from the serialized Dag alone.XComArgBindingregainsmap_index(which upstream row to pull — expand over a mapped upstream) andelement_index(take element N of the unmapped list — expand over an unmapped upstream's output).ti_run): for a mapped stub, bindings are derived per map index by decomposing the TI'smap_indexinto one sub-index per expanded kwarg via newSchedulerDictOfListsExpandInput.resolve_expansion_sub_indexes— the server-side twin of the SDK's_expand_mapped_fieldcross-product (last kwarg varies fastest). Expanded kwargs getmap_index/element_index,partial()kwargs and unpassed defaults bind as above.None→ keep the legacy ignored-args behavior (their args were never deliverable). The provider's parse-time rejections are re-checked server-side for Dags produced by other provider versions.arg_binding_paramdefinition + optional_mapped_arg_binding_paramsarray on the operator; the inner object stays open so newer metadata keeps validating on older cores. NoSERIALIZER_VERSIONbump (optional field).Was generative AI tooling used to co-author this PR?