scheduled-fallback-check-cites-stale-task-id

Scheduled fallback check cites a stale, superseded task ID

Problem

You dispatch a long-running background task — a local gate run, a build, a deploy-verification watcher — under some task ID. Before it (or its successor) is expected to finish, a check-in message arrives asking you to look at that ID and, if it's finished green, take a consequential next step:

"Check whether the fresh gate_receipt.py run (background task b5eomsgw3, output at .../tasks/b5eomsgw3.output) has finished. If it finished green, publish the receipt ... then push."

The trap: between when that check was WRITTEN/SCHEDULED and when it FIRES, the world moved. You found a bug, fixed it, and had to re-run the same class of task from scratch — under a brand-new task ID. The cited ID didn't update; it's a snapshot frozen at scheduling time. By firing time it may refer to a run that:

• already finished (against an OLDER, now-superseded tree), or
• was killed/abandoned, or
• never existed under that exact ID at all (a copy/paste from an earlier turn).

Acting on the cited ID at face value — reading its output, treating "exit 0" there as "the current work is done" — produces a report or an action about the WRONG run. If the follow-on action is consequential (publish a gate receipt, merge, deploy, delete), you've just certified or shipped the wrong tree while believing you verified the current one.

Context / Trigger Conditions

ALL of the following:

1. You (or a peer, or a scheduled wakeup) previously dispatched a long-running background task under task ID A, doing CI-equivalent or otherwise gating work (a full local test/gate run, a build, a deploy watcher).
2. Before A's relevant successor state is reached, something required restarting the SAME class of work — new commits landed, a review round asked for fixes, a merge brought in origin/main, a prior run failed and needed a retry. You started a NEW background task under ID B (or C, or D — this can repeat every time the underlying tree changes again).
3. An incoming message — self-scheduled (ScheduleWakeup/CronCreate firing), a peer session's coordination ping, or a copy-pasted human reminder — names task ID A specifically, often with its output-file path baked in, and gives instructions conditional on A's outcome ("if finished green, do X").
4. The message may explicitly say it's "not a fresh invocation, just a fallback check" — this describes the ORIGIN of the check, not the CURRENCY of the ID inside it. Don't read that framing as license to trust the ID; it's actually the tell that the ID could be stale, because a genuinely fresh check would name whatever is running NOW.