--- id: "bug-1804" status: "fixed" status_updated: "2026-09-24" status_note: "" component: "scheduler" severity: "unknown" timestamp: "2026-09-11T09:55:00Z" last_seen: "2026-09-19T09:00:00Z" occurrences: 1 files: [".kiro/specs/scheduler-sim-eager-reconciliation/{requirements", "design", "research", "tasks", "spec.json}", "src/scheduler/src/sim_loop.c"] tags: ["scheduler", "sim", "replay", "sim_reconcile_unaccounted_jobs", "sched_commit_decision", "job-state", "job-lifecycle", "resource-accounting", "resInUse", "design-fork", "scheduler-sim-eager-reconciliation", "spec-revision", "user-directed", "bug-1624", "driver-equivalence", "tdd"] related: ["bug-1613", "bug-1611", "bug-1624", "bug-1799", "bug-1801"] legacy: true gitea_issue: 273 gitea_synced_status: "fixed" --- # bug-1804: User design assertion (same live replay session as bug-1799/1800/1803): 'according to the design… ## Description User design assertion (same live replay session as bug-1799/1800/1803): 'according to the design, when a job has been scheduled by scheduler, we can say job is running in scheduler angle' -- directly challenging this session's own earlier explanation that a job showing DISPATCH-then-still-PEND for multiple sessions was 'by design, not a bug' (deferred-until-confirmation semantics from the scheduler-sim-eager-reconciliation spec). User asked for confirmation and, once confirmed as a genuine design fork (not a bug in the then-current implementation), explicitly directed adopting the OTHER interpretation: revise the spec to match normal-mode's own synchronous dispatch-commit semantics (bug-1624). ## Environment _Not recorded (migrated from buglog.json)._ ## Reproduction _Not recorded (migrated from buglog.json)._ ## Root cause Not a bug in the sense of an implementation defect -- a genuine, previously-researched design fork between two defensible readings of 'job->state during replay': (a) reconstruct what the ORIGINAL live scheduler process's own job->state field actually held (RUN, synchronously, the instant sched_commit_decision() decided to dispatch -- bug-1624), vs (b) track the SEPARATELY-recorded JOB_STATE_CHANGE/worker-confirmation event's own timing as the operative signal (the scheduler-sim-eager-reconciliation spec's originally-shipped, explicitly-researched choice -- its research.md's own 'Does bug-1624's normal-mode fix already close this gap?' entry correctly noted bug-1624 is a live in-memory write, not a recordable event, so a recording's own JOB_STATE_CHANGE event genuinely CAN land rounds after its DISPATCH decision even post-bug-1624 -- a true fact, but the spec then chose interpretation (b) on top of that fact without it being forced). Live operator use surfaced interpretation (b)'s practical cost directly: a job showing PEND in `info jobs`/`info worker` for multiple sessions after its own `[sim] DISPATCH` line had already printed, reading as a scheduler bug even though it was working exactly as the shipped spec specified. ## Fix FIXED (2026-09-11, user-directed). Adopted interpretation (a): `sim_reconcile_unaccounted_jobs()` (sim_loop.c)'s FOUND branch now sets `job->state = JOB_STAT_RUN;` synchronously, in the same operation as the allocation capture (`job->allocs`/`job->accounts`), mirroring `scheduler.c`'s `sched_commit_decision()` (bug-1624) exactly. `sched_account_jobs()`'s own unchanged `JOB_IS_RUN` gate therefore charges the job's resInUse starting the SAME round as capture, not a later confirmation round. A later, separately-recorded `JOB_STATE_CHANGE`/`JOB_UPDATE`-to-RUN event, when it replays, is now a safe idempotent re-affirmation (RUN->RUN, `core_events.c`'s handler reassigns `job->state` unconditionally with no charging side effect) rather than the sole state-transition trigger. Revised the full `scheduler-sim-eager-reconciliation` spec in place (requirements.md Requirement 1's ACs 1.2-1.5 rewritten, Boundary Context's out-of-scope bullet corrected; design.md's Overview/Non-Goals/Boundary Commitments/Architecture flowchart/System Flows sequence diagram/Requirements Traceability/Service Interface doc/Testing Strategy all updated with dated 'Correction (2026-09-11)' notes, not silently rewritten; research.md's own 'Does bug-1624 already close this gap' entry got a superseding revision note explaining the (a) vs (b) trade-off explicitly, since the original factual finding was correct and remains true -- only the DECISION built on top of it changed; tasks.md got a new task 4/4.1/4.2 documenting the revision, both marked done; spec.json's updated_at bumped). TDD: renamed/inverted test_captured_pend_job_excluded_from_resinuse_until_run to test_captured_job_included_in_resinuse_same_round_as_capture (test_sim_reconcile_unaccounted.c) -- asserts job->state==RUN and resInUse charged immediately after capture (no separate job->state write needed), plus a new Requirement-1.4 companion check that a redundant RUN->RUN confirmation event (driven through the REAL XCE_CORE_EVENT_JOB_STATE_CHANGE handler) doesn't touch the allocation and doesn't change what gets charged after a proper core_reset_workers()-then-sched_account_jobs() round boundary (the test's own first draft skipped that reset before its second sched_account_jobs() call, an artificial double-charge that can never happen in real per-round production flow -- caught by RED/GREEN, fixed in the test, not the production code). Also rewrote test_sim_contention_parity.c's entire second test (test_contention_capacity_check_correct_across_multi_round_dispatch_confirm_gap) -- a 300+ line fixture/assertion block built around the OLD 'deferred until confirmation, partial-then-full usage across rounds 1/4/5' narrative -- to the NEW 'both dispatched jobs saturate capacity immediately at round 1; the later confirmation events are safe no-ops' narrative, since the old assertions (capacity free at round 1, only-A-charged at round 4) are now factually backwards. Audited every other file calling/depending on sim_reconcile_unaccounted_jobs() (test_snapshot_save_load.c, test_sim_snapshot_reconcile_gap.c, test_repl_resource_table.c, test_sim_round_boundary_reconciliation.c, test_sim_e2e_original_motivation.c, test_sim_verify.c) and confirmed each is unaffected: their fixtures either put the DISPATCH and JOB_STATE_CHANGE in the SAME round (a no-op change under the new synchronous-capture semantics, since the job was already RUN via the explicit event before reconciliation ever ran) or never rely on job-state/resInUse timing at all (pure --sim-verify decision-content comparisons, or jobs that are never captured by this mechanism in the first place). RED confirmed (temporarily reverted the `job->state = JOB_STAT_RUN;` line, rebuilt: exactly the 2 updated tests failed for the expected reasons, 75 others green). GREEN confirmed after restoring: full scheduler suite 77/77 Ok, zero regressions. ## Verification _Not recorded (migrated from buglog.json)._ ## References - Related: bug-1613, bug-1611, bug-1624, bug-1799, bug-1801 - Gitea: #273