Repository navigation
TS SDK: resolve upstream XComs for bound TaskFlow arguments - #73190
Merged
jason810496 merged 1 commit intoSep 18, 2026
Merged
Conversation
This was referenced Sep 15, 2026
jason810496
force-pushed
the
feature/ts-sdk/taskflow-xcom-args
branch
14 times, most recently
from
September 18, 2026 03:16
01a48dc to
adc4694
Compare
jason810496
force-pushed
the
feature/ts-sdk/taskflow-xcom-args
branch
3 times, most recently
from
September 18, 2026 09:28
48e7ebc to
3f43c95
Compare
jason810496
marked this pull request as ready for review
September 18, 2026 09:36
jason810496
requested review from
amoghrajesh,
ashb,
bugraoz93,
gopidesupavan,
jscheffl and
potiuk
as code owners
September 18, 2026 09:36
A Python Dag calling a TypeScript task TaskFlow-style, as in `summarize(extract())`, means "hand the handler what extract returned". But the runtime could only bind literals: an argument taking an upstream task's output failed the task and told the author to pull the XCom by hand, so the call site stopped being the contract exactly where it mattered most. Airflow names the upstream task in the binding spec, so the runtime pulls those outputs itself, all of them at once, since a task called with four upstream outputs should wait for one round-trip rather than four. The whole spec is still checked before anything is pulled, so a binding this SDK cannot honour costs no round-trip. They resolve before the handler is called, which is also the one stretch of a task's life with nothing else listening for termination, so the task's abort signal now cuts them short instead of leaving a killed task to sit out the force-exit grace period. An upstream that pushed no output fails the task, naming both the argument and the task it came from: a task that returns nothing pushes no XCom, and an unbound argument corrupts the handler's output rather than stopping it. Telling that apart from an upstream that pushed null takes more than the task client's JS-friendly `getXCom`, which answers null for both, so the coordinator's own client keeps the found flag the supervisor already sends. Handlers stay typed against `TaskClient` and never see it. A Python `int` beyond the range a JavaScript number holds exactly is refused for the same reason: Airflow stamps `format: "int64"` on the argument, and the value arrives with its low digits already lost, so binding it would hand the handler a different number from the one the Dag produced. What does not change is ADR-0001 decision 6: an upstream's return value is not a bound argument unless the call passes it.
jason810496
force-pushed
the
feature/ts-sdk/taskflow-xcom-args
branch
from
September 18, 2026 13:52
3f43c95 to
1e94738
Compare
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
2 participants
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.
TS SDK: resolve upstream XComs for bound TaskFlow arguments
Why
summarize(extract())means "hand the handler what extract returned", but only literals could bind,so such an argument failed the task and told the author to pull the XCom by hand.
How
return_valueXComs itself, all of them concurrently:a task called with four upstream outputs waits for one round-trip, not four.
and leaves no half-resolved call behind.
so the abort signal cuts the pulls short rather than leaving a killed task to sit out the force-exit grace period.
Telling that apart from an upstream that pushed null needs more than
getXCom, which answers null for both,so the coordinator's own client keeps the found flag the supervisor already sends. Handlers stay typed against
TaskClientand never see it.intbeyond the range a JavaScript number holds exactly is refused rather than bound.Airflow stamps
format: "int64"on the argument, and the value arrives with its low digits already lost, so nothing downstream could notice.Note
ADR-0001 decision 6 is unchanged: being upstream is not being passed.
A
>>dependency still declares order only, and a value the call did not pass is still read explicitly.Was generative AI tooling used to co-author this PR?