TS SDK: add triggerDagRun to the native Dag surface

[jason810496]

TS SDK: add triggerDagRun to the native Dag surface

• Depends on TS SDK: add multi-way branching with dag.switch #73444 get merged first (only the last commit is new here).
• Diff for early review: jason810496/airflow@feature/ts-sdk/multi-way-branching...feature/ts-sdk/trigger-dag-run
• next: TS SDK: cover native TypeScript Dags end to end #73446
• 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

Decision 4 of airflow-core/adr/lang-sdk/0008-control-flow-constructs.md, amended here: triggering another Dag's run is an ordinary task the SDK's own runtime runs, so a native Dag needs no Python worker.

How

const trigger = dag.triggerDagRun({
  taskId: "trigger_downstream",
  dagId: "downstream_etl",
  waitForCompletion: true,
  deferrable: true,
});

trigger.after(loaded);

• The task takes no TypeScript arguments, so it hands back the reference directly. A second options object carries the task's own spec.
• It has no handler. The TypeScript runtime runs it the way Python runs TriggerDagRunOperator: it sends TriggerDagRun, polls with GetDagRunState for waitForCompletion, and with deferrable defers to DagStateTrigger, which runs in the Python triggerer, and resumes on execute_complete.
• It inherits the Dag's queue like any other task. It serializes as a TypeScript task drawn as TriggerDagRunOperator, keeps the "Triggered DAG" link, and is recorded in dag_dependencies.
• Values are sent as written, with no Jinja. allowedStates and failedStates take DagRunState values, checked when the Dag is built.
• [api] base_url, [operators] default_deferrable and [triggerer] queues_enabled come from the runtime's environment, read where Python reads them, with Python's fallbacks when unset. The coordinator exports them from Airflow's config in Parse native Lang-SDK Dags with their coordinator's runtime #73842; until then only values set in the worker's environment reach the runtime.
• ADR 0008's consequence that the trigger task runs in Python is amended.

What

• dag.triggerDagRun, on the Dag and on a task group, and coordinator/trigger-runner.ts, which runs it.

Follow-ups

• Decision 2 of airflow-core/adr/lang-sdk/0009-provider-operators-as-generated-dsl.md says a provider DSL task runs on a Python worker, which a task of a native Dag cannot do. It needs its own amendment.
• The docs preview in Update the TypeScript SDK docs for Dags declared in TypeScript #73875 still says the trigger runs on a Python worker and that its Jinja is rendered.

---

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

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

[jason810496]

Finished in #74071.