---
id: "bug-1609"
status: "fixed"
status_updated: "2026-09-24"
status_note: ""
component: "scheduler"
severity: "unknown"
timestamp: "2026-08-20T21:10:00Z"
last_seen: "2026-09-19T09:00:00Z"
occurrences: 1
files: ["src/scheduler/src/repl_break.c"]
tags: ["repl", "sim", "verbosity", "continue", "ux", "scheduler-sim-diagnostics", "scheduler-sim-repl-verbosity"]
related: ["bug-1595", "bug-1763"]
legacy: true
---

# bug-1609: User-reported (live REPL session, xce_scheduler -i -s <replay>): after 'continue' with zero…

## Description
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').

## Environment
_Not recorded (migrated from buglog.json)._

## Reproduction
_Not recorded (migrated from buglog.json)._

## 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
FIXED (2026-09-02, scheduler-sim-repl-verbosity spec, task 3.2 -- design.md's Event Echo Gate component, Requirement 1). Close to the originally proposed shape, refined per design.md's fuller classification: xce_repl_on_event() (repl_break.c) now calls a new repl_event_is_structural(ev->type) classifier before deciding whether to call repl_print_event_summary() -- CONFIG_PUSH/JOBS_PUSH/WORKERS_PUSH/RESOURCES_PUSH/RESVALS_FULL (structural) are always echoed regardless of rs->mode (AC 1.3), while RESVALS_DELTA/JOB_STATE_CHANGE/JOB_UPDATE/QUEUE_UPDATE/JOB_RUSAGE (routine) are echoed only when rs->mode == XCE_REPL_MODE_STEP (AC 1.1/1.2), so `continue` now genuinely reduces output versus single-stepping, exactly this bug's original complaint. Breakpoint matching (repl_find_event_breakpoint()) is unaffected by the classification -- runs on every event regardless (AC 1.4), same as before. A structural event's own line, and a breakpoint-triggered repl_command_loop() re-entry (in xce_repl_on_event()/xce_repl_on_begin_round()/xce_repl_on_decision()), now also call repl_round_collapse_flush() (task 2.2, repl_rollup.c) first, so a mode-suppressed stretch of routine events that got collapsed into a Round Rollup range is reported before either of those (Req 3.5/3.6) -- a Requirement 2/3 dependency this bug's original proposal didn't anticipate (Round Rollup didn't exist yet in task 12.5's original codebase). TDD: task 3.1's RED-phase test_repl_event_echo.c (4 tests, real forked-child stdout-capture against sched_sim_driver_run()) pinned this exact contract before the fix landed; all 4 pass after. Full scheduler suite verified via /xce-build scheduler --incremental: 56/58 test binaries OK, the 2 failures being the pre-existing unrelated bug-1758 (test_core_events.c mem-reservation reconciliation) and a one-off ASAN stack-use-after-return in sched_sim_record_output_test logged separately as bug-1763 (same pre-existing thread-lifecycle class as bug-1598/bug-1632, triggered by this task's repl_break.c size change perturbing that binary's stack layout, not a correctness defect in this fix -- 4/4 isolated re-runs of that binary were clean).

## Verification
_Not recorded (migrated from buglog.json)._

## References
- Related: bug-1595, bug-1763