[jason810496]

Backport of #75795 to v3-4-test, needed before 3.4.0 RC.

Why

Starting any task deserialized its whole Dag, so that ti_run could find out whether the task was a stub and read its arg_bindings. On a Dag cache miss that is a full serialized_dag read plus deserialization per task start, paid while the route holds SELECT ... FOR UPDATE on the task_instance row, and for a Python task the result is thrown away.

How

The serialized is_stub flag is denormalized onto task_instance, which ti_run already fetches and locks, and is checked first so the normal Python task path never loads the serialized Dag.

Null means "not a stub", with no fallback. Every null row predates the migration, so it was written by 3.3, which has no arg_bindings at all, and such a task behaves exactly as it did there.

Go and Java now write is_stub for a TriggerDagRun task too, as TypeScript already does. The worker picks a runtime by queue and both SDKs put such a task on the Dag's queue, so their own runtime runs it and ti_run has to treat it as a stub.

What differs from #75795

• No revision renumbering. ee86eed19e24 is this branch's head, so b4f1a7d2c903 simply follows it and becomes the new head. On main the same revision had to be inserted ahead of two 3.5.0 revisions.
• No execution_timeout change. [v3-4-test] Revert "Enforce execution_timeout for tasks run by a language SDK" (#75376) #75469 took Enforce execution_timeout for tasks run by a language SDK #74869 back out of v3-4-test, so there is no TIRunContext.execution_timeout here and the route keeps its single get_arg_bindings(dag_bag, ti, session=session) call, which the new gate short-circuits.
• test_ti_run_skips_queued_duration_metric_when_the_response_fails sets ti.is_stub = True. Here the gate short-circuits the mocked get_arg_bindings without it; on main the gate only decides whether the task is loaded, so the line is not needed there.

Everything else, including the SDK change, the tests and both fixture fixes, is the same.

Unrelated: one red test on this branch

test_find_executable_task_instances_skips_dag_that_cannot_be_deserialized fails on v3-4-test without this backport, at the branch tip (run 40591272593 on 905a81976cc). #75745 brought the guard over from #75263 without the starved set #75263 relies on, since that set came with #70307, which is not on this branch. The guard then returns False without narrowing the next query, so a cycle whose batch is filled by the bad Dag ends with nothing queued.

The last commit here starves the Dag instead, which is what the test asserts and what the existing starved_dags set is already wired for. Happy to split it into its own PR if that reads better.

---

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

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