Rongsong Shen
d26ff8870d
The buglog was one 27K-line JSON file whose fields covered only symptom,
root cause and fix, as free text: 2% of entries named the code version a
bug was found on, 12% the build profile, 36% a way to reproduce, and 58% of
the file was OpenWolf hook auto-detections ("Missing guard clause",
"Function not marked async" on .md files).
- .claude/skills/buglog/bug-record.md: the record standard. Eight
sections (Summary as the title, Description, Environment, Reproduction;
Root cause, Fix, Verification, References once fixed), each with the
content it must contain -- e.g. Environment needs the OS, the libc the
failing binary loads (from its ELF interpreter: glibc 2.42 in the nix
shell vs 2.40 on the host), toolchain, build profile and commit.
- .wolf/bugs/<id>.md: 500 records migrated from buglog.json; every field
verified to round-trip. They carry legacy: true and an explicit "not
recorded" where the old log had no such field; component derived from
file paths, severity from keywords (else unknown), fix_commits from
hashes in status_note/fix that git resolves (91 of 463 fixed).
- .wolf/buglog-archive.json: the 710 hook auto-detections, verbatim.
- .wolf/buglog.json is now an index generated from the records, keeping
the fields OpenWolf's hooks and `openwolf bug search` read.
- scripts/buglog.py rewritten: new (template + Environment collected from
the machine and --binary), check, status (refuses a status the record
doesn't support; fixed needs Root cause, Fix, Verification and
--commit hashes git resolves), note, recur, set, show, list, triage,
env, index. 29 unittest cases in scripts/tests/test_buglog.py.
- scripts/git-hooks/pre-commit runs `check --staged`: incomplete staged
records, a legacy record hand-changed to fixed without the fix-time
sections, a new record claiming legacy: true, or a stale index refuse
the commit.
- scripts/gitea-sync.py reads the records: issue body = the record's
sections plus linked fix commits (origin remote, GITEA_COMMIT_REPO to
override), and a body hash so an issue's text is refreshed when the
record changes.
- bug-1866 rewritten to the full standard as the worked example.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
8 KiB
| id | status | status_updated | status_note | component | severity | timestamp | last_seen | occurrences | files | tags | related | legacy | gitea_issue | gitea_synced_status | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| bug-1838 | fixed | 2026-09-24 | scheduler | unknown | 2026-09-21T00:30:00Z | 2026-09-21T02:40:00Z | 1 |
|
|
|
true | 70 | fixed |
bug-1838: Follow-up architectural correction after bug-1836 (found during user discussion, not a…
Description
Follow-up architectural correction after bug-1836 (found during user discussion, not a separately-reported live symptom): even with bug-1836's capacity gate in place, sim_reconcile_unaccounted_jobs() still unnecessarily PREEMPTED the live picker/allocator for any freshly-PEND job with a matching recorded DISPATCH decision, rather than letting the live path -- now genuinely capacity-checked, per scheduler-sim-live-allocation -- decide it on its own the way normal mode always has. User specifically asked why sim mode diverged from normal mode given they 'share the same core', then proposed the architecturally correct framing directly: the simulator should run the identical decision-making core (minus controller/worker I/O) and use the recording only to verify/reconstruct, not to short-circuit live decisions.
Environment
Not recorded (migrated from buglog.json).
Reproduction
Not recorded (migrated from buglog.json).
Root cause
sim_reconcile_unaccounted_jobs()'s trigger condition was widened from JOB_IS_RUN-only to state-independent (PEND-or-RUN) by the scheduler-sim-eager-reconciliation spec (2026-09-11), to fix a real problem at the time: a job's recorded DISPATCH decision only exists in the ONE round's decoded_session it was captured in (freed at round end), so a RUN-only gate meant reconciliation could never find it once the job's SEPARATE, later-replayed RUN-confirmation event finally made it RUN. That widening was the only available fix at the time because sim mode's own live picker/allocator path had no working capacity accounting (bug-1613) and so could not be trusted to independently re-derive the SAME decision the original recording made -- reconciliation's job was to force in the recording's answer since the live path's own answer might diverge or be wrong. scheduler-sim-live-allocation (completed 2026-09-19) closed that gap for real: sim mode now spawns the SAME real, capacity-checked sched_job_picker()/sched_allocator() threads (sched_election.c) normal mode does, with sched_account_jobs() correctly wired into its round sequence -- its own design.md explicitly states a 'Live/Recorded Authority Rule' (live decision wins when the live path reaches a job; reconciliation is a narrow safety net, not a first-resort source of truth) but the actual per-round ORDERING (reconciliation runs unconditionally before the live picker/allocator gets a turn each round) never enforced that rule -- so the PEND-inclusive trigger left in place after scheduler-sim-live-allocation landed kept preempting jobs the live path was now fully capable of deciding correctly and verifiably on its own. This was the deeper root cause underlying bug-1836's exact reproduction (44 jobs force-dispatched via reconciliation before the live picker/allocator ever got a turn); bug-1836's capacity gate made that force-application SAFE (never exceeds real capacity) but did not stop it from happening. Also confirmed (via direct investigation): a snapshot-loaded job (snapshot_load.c's xce_sched_core_load_snapshot()) is registered with the live picker via on_job_push() for every restored job unconditionally, RUN or PEND -- so there is no 'invisible to the picker' case a RUN-only trigger could miss; every legitimate reconciliation candidate today is also, structurally, a job the live picker/allocator can independently resolve. The sole remaining genuine case: a job already RUN before this replay's own observation window (dispatched too far in the past for its DISPATCH decision to still be in any currently-decoded session, and never offered by next_job() since RUN jobs are never picker candidates) -- for that job alone, the recording remains the sole source of truth.
Fix
FIXED (2026-09-21). Narrowed sim_reconcile_unaccounted_jobs()'s trigger back to JOB_IS_RUN(job->state)-only (undoing the 2026-09-11 widening), so a freshly-PEND job now always flows through the same real, capacity-checked live picker/allocator normal mode uses -- verified via the pre-existing --sim-verify generate-then-compare mechanism -- rather than being force-applied from history. bug-1836's capacity gate (sim_reconciled_alloc_fits_capacity()/sim_reconcile_toggle_prior_charges()) remains in place unchanged as defense-in-depth for the narrower remaining RUN-only case. Fixing this correctly broke 6 test binaries whose fixtures depended on the old PEND-inclusive behavior; investigation of each was more nuanced than initially guessed: test_sim_verify.c's and test_sim_contention_parity.c's failures were NOT missing-worker-registration issues (the initial hypothesis) but rather that those two files each stub sched_job_picker()/sched_allocator() to a deliberately PEND-only pair (used to keep their OTHER, unrelated tests decoupled from real dispatch logic) -- under the new design a PEND job in those fixtures genuinely can never be dispatched by anything, so the correct fix was inverting each test's assertions to lock in the new, correct behavior (a PEND job stays PEND, and --sim-verify correctly reports the resulting MISMATCH against a history that shows it dispatched, since these minimal harnesses have no real capacity-tracked path to reproduce that decision) rather than trying to make the stub dispatch something it structurally cannot. The 5 directly-affected tests in test_sim_reconcile_unaccounted.c were each individually re-examined for their TRUE intent and fixed accordingly: one inverted/renamed to lock in 'PEND is now always ignored regardless of a matching decision' (test_reconcile_ignores_pend_state_job_even_when_dispatch_recorded), three converted from a PEND-starting to a RUN-starting fixture job (still meaningfully testing the same underlying resInUse-timing/retry/multi-round mechanics, now via the only state that's still eligible), and one (the bug-1759/1779 on_dispatch-retirement regression test) kept its job PEND-built-then-force-set-to-RUN specifically to reproduce the pathological 'RUN job the picker was never told about' state reconciliation's on_dispatch() safety net still needs to guard against, since no real production path can reach that shape anymore post-bug-1838. A sweep for other coincidentally-passing tests found and fixed one more: bug-1836's own new regression test (test_reconcile_respects_host_capacity_under_contention) also used two PEND jobs, converted to RUN with its 'loser' assertion corrected to match. Added a new live-dispatch-vs-recording round-trip test (test_sim_live_allocation.c) to restore the coverage inverting test_sim_verify.c's test removed (that a genuinely live-dispatched decision correctly reproduces a matching historical recording when both the job and the resources it wants are real). scheduler-sim-eager-reconciliation's own requirements.md/design.md got dated 'Correction (2026-09-21, bug-1838)' notes in place, following the exact precedent format its own 2026-09-11 correction already established, superseding (not deleting) the original PEND-inclusive Acceptance Criterion 1 text. Verified: full scheduler suite 85/85 Ok, 0 Fail (asan profile); independently re-confirmed by running sched_sim_reconcile_unaccounted_test (22/22), sched_sim_verify_test (17/17), sched_sim_contention_parity_test (2/2), and sched_sim_live_allocation_test (2/2) directly.
Verification
Not recorded (migrated from buglog.json).
References
- Related: bug-1836, bug-1837, bug-1611, bug-1613, bug-1759, bug-1779, bug-1804
- Gitea: #70