Rongsong Shen
3c4091d88b
The original motivating recording (scheduler-replay-20260820-070103.replay, named in bug-1611) no longer exists anywhere on disk -- confirmed via exhaustive filesystem search. Substituted a real, driven 24-round/12-job resource-constrained recording using actual driver.c/builtin_fcfs/resource.c code, replayed through the real, unmodified interactive REPL. This also surfaced and honestly documents a real structural limit: Recorded-Decision Reconciliation only succeeds when a job's recorded DISPATCH decision and its JOB_STATE_CHANGE-to-RUN confirmation land in the SAME replay round (reconciliation searches only that round's own decoded data). Constructing that exact coincidence from organic, continuous scheduling is structurally impossible -- a job can't be both "freshly PEND for this round's picker" and "already RUN before this round's picker runs" at once. One job (ANCHOR_ID) engineers this coincidence using entirely real constructors (matching the same precedent tasks 3 and 4.1 already established); the other 11 jobs arrive/contend/dispatch/finish with zero special-casing across all 24 real rounds. Recorded in tasks.md's Implementation Notes as a scope finding for follow-up: in a real deployment with genuine dispatch-to-confirmation latency, this narrows the feature's real-world coverage of bug-1611/1613's dominant manifestation. RED phase: reverting task 3's reconciliation call site makes this test fail with the exact bug-1611 symptom in its own assertion message, plus 3 sibling tests break too; restored and green. No production code touched (final task in the feature -- all production work landed in task 3). 50/51 scheduler tests pass; the 1 failure is pre-existing bug-1560 (unrelated). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| settings | ||
| specs | ||
| steering | ||