lei.chen/myxce
1
0
Fork 1
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

chore(wolf): checkpoint buglog.json (991 bugs)

Browse source
This commit is contained in:
Rongsong Shen 2026-08-21 04:19:26 +00:00
parent a860141bb9
commit 13fc840f8c
No known key found for this signature in database
GPG key ID: 5BCDAAE0123E9FE2
1 changed files with 42 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

42
.wolf/buglog.json
View file

@ -17910,6 +17910,48 @@
],
"occurrences": 1,
"last_seen": "2026-08-20T15:57:00Z"
},
{
"id": "bug-1609",
"timestamp": "2026-08-20T21:10:00Z",
"error_message": "User-reported (live REPL session, xce_scheduler -i -s <replay>): after 'continue' with zero breakpoints set, output is just as verbose as single-stepping -- every decoded event still prints a '[sim] t=... session=...' + '[sim] event: ...' two-line block, defeating continue's documented purpose ('Run until next breakpoint hit or EOF').",
"file": "src/scheduler/src/repl_break.c",
"root_cause": "xce_repl_on_event() (repl_break.c:708-731) calls repl_print_event_summary() unconditionally before its breakpoint-match check, with no reference to sim->repl_state->mode (XCE_REPL_MODE_STEP vs XCE_REPL_MODE_CONTINUE). This was intentional for bug-1595 ('in each step, ... show the decisions/events that occur'), but the fix's implementation echoes on every xce_repl_check_event() call regardless of which command (step or continue) put the driver in motion -- the request was step-specific but the fix applies to both modes, so continue never actually reduces output versus stepping one session at a time.",
"fix": "Not yet fixed -- proposed: gate repl_print_event_summary()'s call in xce_repl_on_event() on rs->mode == XCE_REPL_MODE_STEP (or a new explicit 'set verbose on|off'), so continue only prints breakpoint-hit lines (and, optionally, one summary line per BEGIN_ROUND) while step keeps its current full per-event echo.",
"tags": [
"repl",
"sim",
"verbosity",
"continue",
"ux",
"scheduler-sim-diagnostics"
],
"related_bugs": [
"bug-1595"
],
"occurrences": 1,
"last_seen": "2026-08-20T21:10:00Z"
},
{
"id": "bug-1610",
"timestamp": "2026-08-20T21:10:00Z",
"error_message": "User-reported (same live REPL session): under 'continue', an unchanged PEND decision for the same jobid prints an identical '[sim] PEND jobid=...' line every scheduling round it remains pending -- e.g. jobs [22]-[29] (8 jobs) print their 8 byte-identical PEND lines 5+ times in a row across consecutive rounds with zero new information each time.",
"file": "src/scheduler/src/sim_loop.c",
"root_cause": "sim_print_decision() (sim_loop.c:388-411) unconditionally prints one DISPATCH/PEND/PREEMPT line per drained xce_decision_t with no de-duplication and no session/round context attached to the line itself -- called every round a job's allocation is (re-)attempted, so a job that stays PEND for N consecutive rounds produces N identical lines. xce_repl_on_decision() (repl_break.c:776-811), called alongside it, already tallies last_n_pend/last_n_dispatch/last_n_preempt per round for 'info session' -- that rollup exists but is never surfaced automatically, only on explicit 'info session'.",
"fix": "Not yet fixed -- proposed: either (a) only print a decision line the first time a given jobid enters PEND / when its pend reason changes, suppressing repeats of the identical reason, or (b) replace the unconditional per-decision echo with one per-round summary line at BEGIN_ROUND using the tally xce_repl_on_decision() already accumulates ('[sim] round N: X dispatch, Y pend, Z preempt'), reserving full per-decision detail for step mode or a matching breakpoint.",
"tags": [
"repl",
"sim",
"verbosity",
"duplicate-output",
"pend",
"scheduler-sim-diagnostics"
],
"related_bugs": [
"bug-1609"
],
"occurrences": 1,
"last_seen": "2026-08-20T21:10:00Z"
}
]
}