Repository navigation
TS SDK: bind TaskFlow call arguments by folding names on both sides - #73189
Merged
jason810496 merged 1 commit intoSep 18, 2026
Merged
Conversation
This was referenced Sep 15, 2026
jason810496
force-pushed
the
feature/ts-sdk/taskflow-arg-folding
branch
13 times, most recently
from
September 18, 2026 01:26
8eb9c79 to
47e4cba
Compare
jason810496
marked this pull request as ready for review
September 18, 2026 01:44
jason810496
requested review from
amoghrajesh,
ashb,
bugraoz93,
gopidesupavan,
jscheffl and
potiuk
as code owners
September 18, 2026 01:44
A Python Dag declares a task that runs in TypeScript with `@task.stub` and calls it TaskFlow-style, but the handler could not see those arguments: it was called with nothing, so the call site was decoration and its values had to be hardcoded in the handler or re-fetched from XCom. Airflow already delivers that call site as an ordered, named spec in the task's run context. The names are the problem worth solving. Python spells a parameter `region_code` and TypeScript wants to read it as `regionCode`, and making an author declare that for every ordinary snake_case parameter would be a tax on the common case. So names bind by folding on both sides, lowercased with underscores removed, which is exactly the Go SDK's rule. One Python signature then binds identically in either SDK with nothing declared. Folding on read rather than up front is why the bound object is a `Proxy`: the SDK sees Python's names and cannot know which spelling a handler will destructure, so no guess at a TypeScript name is ever materialized. `in` folds like a read, and `Object.keys` and rest destructuring yield Python's names. The object has a null prototype, so a Python argument named `toString` binds like any other and one that was not passed misses rather than resolving to a function. An unmatched name logs rather than throws, since a destructuring default is a legitimate miss and nothing can tell one from a typo. The warning names both the requested name and what the call delivered, and a failing task reports the same list, because a handler that destructured an argument under a name nothing folds to gets no error of its own. Two Python names that fold to one token do fail the task, before the handler runs and naming both: neither could be reached, and picking either silently would hand the handler the wrong value. An XCom-backed binding fails the same way for now, with the getXCom call to write instead. Anything else the SDK cannot honour fails rather than being dropped, because an unbound argument reaches the handler as `undefined` and corrupts its output instead of stopping it.
jason810496
force-pushed
the
feature/ts-sdk/taskflow-arg-folding
branch
from
September 18, 2026 03:16
47e4cba to
e57a0f9
Compare
1 task done
1 task done
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.
Why
We need to support binding the literal defined on
@task.stubto the TS task handler argument.How
ti_context.arg_bindingsmsgpack and hand it to the handler as its parameter.Same as the Go SDK's rule (
strings.ToLower(strings.ReplaceAll(name, "_", "")))So one Python signature binds identically in either SDK, and no need to explicitly rename snake_case by default.
Proxyso folding happens per read when task handler start.The XCom binding will be support in the next PR instead of current one.
Was generative AI tooling used to co-author this PR?