potiuk opened a new issue, #66307: URL: https://github.com/apache/airflow/issues/66307
### 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`](https://github.com/apache/airflow/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*](https://github.com/apache/airflow/pull/55068) (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 #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 #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 #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 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
