[hkc-8010]

Rescheduled tasks currently fetch their first task reschedule start date from the supervisor when RuntimeTaskInstance.get_first_reschedule_date() is called. For sensors, this can happen before poke() starts, which means a worker can block on the supervisor/API round trip before emitting the sensor's usual poke log line.

This PR includes the first task reschedule start date in the task instance run context returned by the Execution API. The Task SDK uses that value directly when present, while keeping the existing supervisor request as a compatibility fallback for older API responses.

closes: #68010

Tests:

• breeze testing task-sdk-tests --python 3.10 -- task-sdk/tests/task_sdk/execution_time/test_task_runner.py -k get_first_reschedule_date -q
• breeze testing core-tests --python 3.10 --db-reset -- airflow-core/tests/unit/api_fastapi/execution_api/versions/head/test_task_instances.py airflow-core/tests/unit/api_fastapi/execution_api/versions/v2026_06_30/test_task_instances.py -q
• breeze testing core-tests --backend postgres --python 3.10 --db-reset -- airflow-core/tests/unit/api_fastapi/execution_api/versions/head/test_task_instances.py airflow-core/tests/unit/api_fastapi/execution_api/versions/v2026_06_30/test_task_instances.py -q
• breeze testing task-sdk-tests --python 3.10
• prek run --files <changed-files>
• prek run --files <changed-files> --stage manual

---

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

• Yes (please specify the tool below)

Generated-by: OpenAI Codex following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

---

Important

🛠️ Maintainer triage note for @hkc-8010 · by @potiuk · 2026-08-13 12:55 UTC

Helpful heads-up from the maintainers — please address before this PR can be reviewed:

• ❌ Provider tests. See docs.

Full list of what we check: Pull Request quality criteria.

The ball is in your court — you've been assigned to this PR. Fix the above, then mark it Ready for review.

_{Automated triage — may be imperfect; a maintainer takes the next look.}

[potiuk]

@hkc-8010 A few things need addressing before review — see our Pull Request quality criteria.

• ❌ Merge conflicts with main. See docs.

No rush.

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this two-stage triage process so that our maintainers' limited time is spent where it matters most: the conversation with you.

[hkc-8010]

@potiuk thanks for the heads up. I rebased the branch on current main, resolved the conflicts, and force-pushed the updated commit (f3bd4aae0da6ad23a2b06500b6c9354dec140a77).

The local pre-push hooks are passing now, including the supervisor schema snapshot/version checks that caught one missing generated snapshot update during the rebase. GitHub checks have restarted on the updated commit.

Could you please take another look when you get a chance?

[Copilot]

Pull request overview

This PR aims to prevent rescheduled sensors from blocking before poke() by including the first TaskReschedule.start_date in the Execution API’s TIRunContext, and teaching the Task SDK to use that value when present (with a supervisor/API fallback for older server responses).

Changes:

• Add first_task_reschedule_start_date to TIRunContext (core + Task SDK generated models/schema) and expose it from the /execution/task-instances/{id}/run response.
• Update RuntimeTaskInstance.get_first_reschedule_date() to use the server-provided context value before falling back to GetTaskRescheduleStartDate.
• Add/adjust backward-compat and Task SDK tests covering presence/absence of the new field.

Reviewed changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
task-sdk/tests/task_sdk/execution_time/test_task_runner.py	Adds a test ensuring the server-provided first reschedule date avoids a supervisor request.
task-sdk/tests/conftest.py	Extends test context factory helpers to support first_task_reschedule_start_date.
task-sdk/src/airflow/sdk/execution_time/task_runner.py	Uses first_task_reschedule_start_date from server context when available.
task-sdk/src/airflow/sdk/execution_time/schema/versions/init.py	Adjusts schema version bundle/lazy import plumbing (currently broken as written).
task-sdk/src/airflow/sdk/execution_time/schema/schema.json	Adds first_task_reschedule_start_date to the Task SDK schema.
task-sdk/src/airflow/sdk/api/datamodels/_generated.py	Regenerates Task SDK datamodels to include first_task_reschedule_start_date.
airflow-core/tests/unit/api_fastapi/execution_api/versions/v2026_06_30/test_task_instances.py	Adds a backward-compat test for stripping the new field for older API versions (currently has duplicated fixture/import block).
airflow-core/tests/unit/api_fastapi/execution_api/versions/head/test_task_instances.py	Adds a head-version test asserting the run context includes the first reschedule start date.
airflow-core/src/airflow/api_fastapi/execution_api/versions/v2026_06_30.py	Adds a Cadwyn version change for the new response field.
airflow-core/src/airflow/api_fastapi/execution_api/versions/init.py	Registers the new version change in the 2026-06-30 bundle.
airflow-core/src/airflow/api_fastapi/execution_api/routes/task_instances.py	Populates first_task_reschedule_start_date from TaskReschedule rows during ti_run.
airflow-core/src/airflow/api_fastapi/execution_api/datamodels/taskinstance.py	Adds the new field to the server-side TIRunContext datamodel.

Comments suppressed due to low confidence (1)

airflow-core/tests/unit/api_fastapi/execution_api/versions/v2026_06_30/test_task_instances.py:43

• This file now contains a duplicate old_ver_client fixture plus a second block of repeated imports/pytestmark. The first fixture has no body beyond a docstring, and the redefinition will be flagged by linters (and is easy to miss in review). Remove the duplicate block so there is only one old_ver_client fixture and a single import section.

@pytest.fixture
def old_ver_client(client):
    """Last released execution API before first_task_reschedule_start_date was added."""
import pytest

from airflow._shared.timezones import timezone
from airflow.utils.state import DagRunState, State

from tests_common.test_utils.db import clear_db_runs

pytestmark = pytest.mark.db_test

[aaron-y-chen]

Brilliant! I have a small suggestion that might be helpful :)

[Copilot]

Pull request overview

Copilot reviewed 13 out of 14 changed files in this pull request and generated no new comments.

[jason810496]

Thanks for the improvement, LGTM overall.

Additionally, would it be better to rephrase the title as improvement instead of the fix? Since w're improving the sensor startup overload by avoiding the additional round trip to retrieve the reschedule date instead of fixing a logical bug.

[hkc-8010]

@jason810496 retitled to "Avoid a supervisor round trip before poke for rescheduled sensors", your framing is more accurate. The change removes the pre-poke round trip rather than fixing a logic bug.

I replied on the three inline nits. I'd rather keep all three as they are and gave the reason on each thread. Happy to change any of them if you disagree.

[potiuk]

Thanks, this looks good to me. I checked that nothing depended on the removed round trip. The value is snapshotted at ti_run, and TaskReschedule rows for a given ti_id are only written when that same attempt reschedules (which ends it) or are deleted together with a new ti.id on clear/retry. So the snapshot always equals what the supervisor request would have returned before poke(), and the sensor timeout / backoff computation is unchanged. The versioning is also right: 2026-10-30 is still unreleased, there are matching Cadwyn changes on both the Execution API and the supervisor schema, and the SDK falls back for older servers.

It conflicts with main again: new entries were added to both 2026-10-30 version bundles since your last rebase. Could you rebase and regenerate the schema/TS artifacts? I'm happy to approve once CI is green.

One optional nit: GET /task-reschedules/{ti_id}/start_date (routes/task_reschedules.py) still picks the first row by order_by(TaskReschedule.id), while ti_run now uses min(start_date). They are equivalent in practice, but using min(start_date) in both places would keep the two definitions from drifting. Fine as a follow-up.

---

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

[hkc-8010]

@potiuk Rebased onto main and regenerated the schema/TS artifacts. They came out unchanged after the merge, and both 2026-10-30 bundles now carry main's new entries alongside this one. I also took the nit: get_start_date now uses min(start_date) like ti_run, with a test that inserts reschedules out of order so the old order_by(id) query fails it. It's on the async session version main switched to in #73403.

[potiuk]

Thanks — that's everything. The rebase picked up main's new 2026-10-30 entries cleanly, and with min(start_date) in both places the two definitions can't drift; the out-of-order test pins it. Approving; merging once CI is green.

---

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

[potiuk]

@jason810496 could you take another look and confirm you're OK with this as it stands? hkc-8010 rebased and addressed the follow-up from my review, and replied on your three remaining threads (TIRunContext construction, the uuid7 import, and the older-server comment) explaining why they'd prefer to keep them as they are. I'll hold off merging until you've had a chance to re-review — if you're happy with the replies, please resolve the threads.

---

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

[potiuk]

I pushed a fixup (fab4d19) to get static checks green. The PR adds first_task_reschedule_start_date to the Task SDK supervisor schema, and the Go SDK keeps a vendored copy of that schema plus models generated from it, so sync-go-sdk-schemas and check-go-sdk-generated-drift failed. The commit refreshes go-sdk/schema/supervisor-schema.json and regenerates go-sdk/pkg/execution/genmodels/models.gen.go. Next time the schema changes, running those two prek hooks (they need the Go toolchain) does the same. Please pull before pushing again.

---

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

[amoghrajesh]

Nits, otherwise LGTM

[kaxil]

Thanks, LGTM