TS SDK: name a task's inputs, and take its id from the handler

[jason810496]

• Diff for early review: main...jason810496:airflow:feature/ts-sdk/default-task-id-at-pack-time
• next: TS SDK: draw order-only edges with before and after #73438
• TS SDK: generate Dag and task options from the serialization schema #73436 is merged, so this one applies to main on its own.
• Part of the native TypeScript Dag stack, TS SDK: declare task dependencies by calling tasks #73435 to TS SDK: cover native TypeScript Dags end to end #73446, to be merged in order.

Why

Every argument reaches the serialized Dag by name, and a positional parameter list has none unless the SDK reads them out of the handler's source. A handler that takes one object of named arguments is what a TypeScript library takes anyway, and it settles both ends: the call site carries the names, and the handler's own name is still the task id.

const transform = dag.task(
  "transform",
  async ({ rows, region }: { rows: number; region: string }) => rows * 2,
);

transform({ rows: extracted, region: "us" });

How

• A call records its own keys, so nothing reads a function's parameter list and no argument is ever labelled arg0. TaskOptions.argBindings is gone with it.
• A handler that declares more than one parameter, or a call given more than one argument, is an error, so a positional call from plain JavaScript fails instead of losing a value.
• dag.task(handler) takes its id from handler.name, and TaskSpec.taskId sets one for an anonymous handler. Giving the id twice is an error rather than a silent winner.
• airflow-ts-pack passes esbuild's keepNames, so the id survives minification.

ts-sdk/adr/0002 records the positional handler as tried and dropped. An earlier revision of this PR read the names at pack time with an esbuild onLoad hook and TypeScript's parser; it needed a parser in the packer and could not see a handler declared in another module.

---

Was generative AI tooling used to co-author this PR?

• Yes, with help of Claude Code Opus 5 following the guidelines

[pierrejeambrun]

Nice thanks.

A few minor comments

[pierrejeambrun]

@ashb TS SDK: Retrieve task id from fn name via a plugin to manipulate the source before packaging.

Since this adds some complexity, I'm second guessing if keepNames (basically not minifying names) was a best option

• Would remove most of this code
• Would allow for cleaner debug process, with stack traces pointing to real function names instead of minified ones
• This shouldn't matter in term of bundle 'size' (my agent is hinting at 1-2%), the workers are already pulling tons of dependencies (python stuff), a few extra names shouldn't be that bad. And it shouldn't have a meaningful impact on execution speed as well.

Also common node recommendation for server side is typically not to minify at all. (keepNames can meet best of both world).

(Sorry for the incorrect ping Andrew)

My bad

[jason810496]

Also common node recommendation for server side is typically not to minify at all.

By this way and from your perspective, should we support the tsx way to start the TS SDK runtime?
Since Ash and I had a conversation back in Airflow Submit that Ash would like to have a way to start the TS runtime without bundling. I'm not sure the convention of "bundling or not" for TS server-side project myself.

However, all the current SDKs are heavily rely on the metadata at the artifacts for discovery purpose.
Since this topic is related with this PR so I would like to bring this up.

[ashb]

(Sorry for the incorrect ping Andrew)

[pierrejeambrun]

By this way and from your perspective, should we support the tsx way to start the TS SDK runtime?
Since Ash and I had a conversation back in Airflow Submit that Ash would like to have a way to start the TS runtime without bundling.

We can add this alongside current capability if this helps our users.

I'm not sure the convention of "bundling or not" for TS server-side project myself.

For portability reason i'd say that we still want bundling to happen. (pnpm install + moving whole source file around is probably not great)

[jason810496]

Heads up on one consequence:

Without the plugin, the task id and the argument names are read off the handler when the Dag module "runs" runtime.

The "Runs" here is not the task runtime. It is the Dag module executes during packing, where airflow-ts-pack runs the staged bundle with --airflow-metadata (node bundle.min.mjs --airflow-metadata) to collect the dag ids and task ids for the embedded manifest.

Not sure would it still be more clean if we implement the pack time plugin as last round to retrieve the function and arguments names as TaskSpec.

The design choice between Packing transformation vs Runtime inferring

[pierrejeambrun]

LGTM, two comments we need to address before moving forward.

[jason810496]

Thanks for the review and the discussion.
I just addressed all the comments.

[jason810496]

Thanks for the review Pierre, CI passed while marking the PR as draft.
I will merge the PR now.