Decide fate of `start_from_trigger` on the 3.2 release branch — #55068 missed backport

[potiuk]

Summary

The start_from_trigger feature (operators with start_from_trigger=True
plus start_trigger_args deferring at scheduling time, without occupying
a worker slot) is disabled on v3-2-test but enabled on main.
We need to decide whether to backport it to 3.2 or formally drop the
feature on the 3.2 line.

Background

In commit
91e10295c7d
(2025-08-20), the scheduler's "defer at schedule time" branch in
DagRun.schedule_tis was commented out with a TODO TaskSDK note —
the new TaskSDK architecture didn't yet have a way to render
start_from_trigger template fields in the scheduler.

Later, on main, PR
#55068 — Re-enable start_from_trigger feature with rendering of
template fields
(merged 2026-03-25, +922/-192 across 19 files) re-enabled the feature
by calling ti.defer_task(session=session) from schedule_tis,
backed by template-rendering changes in the templater, triggerer job,
and base operator.

v3-2-test was branched on 2026-03-24, one day before #55068
merged. As a result, the 3.2 release branch ships with the feature
disabled, even though:

• The test airflow-core/tests/unit/models/test_dagrun.py::test_schedule_tis_start_trigger
  was already on the branch (and asserts the feature works).
• Operators in user code on 3.2 that set start_from_trigger=True
  silently fall through to the regular schedulable path — they will
  run on a worker, not be deferred at schedule time. No warning, no
  error.

Concrete failure that surfaced this

CI run on v3-2-test HEAD (5fa97035d6) failed in the Postgres core
test job:

FAILED airflow-core/tests/unit/models/test_dagrun.py::test_schedule_tis_start_trigger
AssertionError: assert equals failed
None != <TaskInstanceState.DEFERRED: 'deferred'>

(Job: https://github.com/apache/airflow/actions/runs/25270258994/job/74097048671)

As a short-term unblock, the test will be skipped on v3-2-test with
this issue linked from the skip reason. Do not close this issue
based on that workaround alone — the underlying decision is still
open.

Options

1. Backport Re-enable start_from_trigger feature with rendering of template fields #55068 to v3-2-test. Restores parity with main
   but pulls in a 19-file feature-PR (templater, triggerer-job,
   base operator changes) into a release branch. Would also need
   any follow-up fixes that landed on main after Re-enable start_from_trigger feature with rendering of template fields #55068. Highest
   user value, highest risk.

2. Formally drop start_from_trigger on the 3.2 line. Document
   the limitation in the 3.2 release notes / "What's not supported"
   section, raise a clear NotImplementedError (or log a warning) when
   an operator with start_from_trigger=True is scheduled on 3.2 so
   users aren't silently surprised, and remove the dead test.
   Lower risk, but it ships a 3.2 feature gap users currently get on
   3.1.

3. Status quo + skip. What the immediate workaround does — keep
   the disabled code path, skip the test. Worst of both worlds for
   the long run; only acceptable as a stopgap.

Recommendation: option 2 unless someone has bandwidth to do option 1
properly (cherry-pick + verify + chase down follow-ups). The 3.2
release notes ought to mention this either way.

Acceptance criteria

• A decision recorded in this issue (option 1 or 2).
• If option 1: PR landing the relevant subset of Re-enable start_from_trigger feature with rendering of template fields #55068 on
  v3-2-test, the skip on test_schedule_tis_start_trigger removed,
  CI green.
• If option 2: a release-note entry on the 3.2 line, a user-visible
  signal (warning or error) when start_from_trigger=True is used
  on 3.2, and the test removed from v3-2-test.

cc @uranusjr (commit author who originally disabled the path) /
@dabla (author of #55068) for context.

---

Drafted-by: Claude Code (Opus 4.7); reviewed by @potiuk before posting

[dabla]

I'm willing to backport this, as I expected this to be part of 3.2 anyway, but at the end wasn't.

But beside the main PR 55068 which re-enables the start_from_trigger feature,
there are also other post fix PR related to it:

64298 which is merged in main
64715 which is also merged in main
64714 which is still open and needs to be merged

So in order to make the backport, it would be better to make sure all PR's are merged in main first.

[dabla]

Beside above mentioned PR, there is also this one by @amoghrajesh:

66002

[potiuk]

I think it's also @vatsrahul1001 decision based on what others involved people say.

[dabla]

Could someone review this PR as well as this was requested by @kaxil but I think he's on leave now?

64714 which is still open and needs to be merged