The comprehensive e2e matrix (tests/e2e/comprehensive-mcp-tools.test.ts) consistently reports a soft FAIL for ruby get_output on Windows:
[✗] get_output (ruby): marker "1: 1" not captured (entries=1)
The cell is reproducible across runs (with and without coverage instrumentation) but is invisible in CI/vitest because the matrix records it softly — the vitest test itself passes, so nothing goes red.
What happens: in the workflow sequence (breakpoint in the fizzbuzz loop → steps/evaluate → continue → 2s wait → get_output), only one output entry (the rdbg REPL banner) has arrived by the time get_output runs. Iteration 1's puts output never arrives as a DAP output event mid-run.
What works: launching the same fizzbuzz.rb without the workflow and letting it run to termination captures everything — banner, fizzbuzz complete (stderr), and all 15 stdout lines, with the stdout entries timestamped together at exit (the #254/#258 exit-flush drain). So capture and forwarding are intact; the gap is specifically mid-run delivery while the session sits paused in the loop — consistent with Ruby block-buffering stdout on a pipe (~8KB buffer that a few fizzbuzz lines never fill), with the flush only happening at exit.
Why it matters: the outputMarker was added in PR #254 with the comment "iteration 1's puts — the loop breakpoint re-arms, so later output isn't guaranteed", i.e. iteration 1 was expected to be captured mid-run. Either that expectation regressed at some point, or it was only ever true on Linux/CI. Unknown since when — the soft cell can't fail a build, so nobody was looking.
Possible directions:
- Force
STDOUT.sync = true (or $stdout.sync) in the rdbg launch path so debuggee output streams instead of buffering, or
- Relax the matrix expectation for ruby to "captured after termination" and make the cell hard-assert that, or
- Make the matrix cell hard-fail so regressions in it are visible.
Ruled out: the #237 redaction hook (session-manager-core handleOutput) — it transforms events that arrive and cannot drop them; the missing marker means the event never arrived, and the arrival path (adapter stdio forwarding, proxy) is untouched by #237. The same hook captured all 17 entries in the direct repro.
Environment: Windows 11, Ruby 3.4 + rdbg, main @ 8c5c2db.
The comprehensive e2e matrix (tests/e2e/comprehensive-mcp-tools.test.ts) consistently reports a soft FAIL for ruby get_output on Windows:
The cell is reproducible across runs (with and without coverage instrumentation) but is invisible in CI/vitest because the matrix records it softly — the vitest test itself passes, so nothing goes red.
What happens: in the workflow sequence (breakpoint in the fizzbuzz loop → steps/evaluate → continue → 2s wait → get_output), only one output entry (the rdbg REPL banner) has arrived by the time get_output runs. Iteration 1's
putsoutput never arrives as a DAP output event mid-run.What works: launching the same fizzbuzz.rb without the workflow and letting it run to termination captures everything — banner,
fizzbuzz complete(stderr), and all 15 stdout lines, with the stdout entries timestamped together at exit (the #254/#258 exit-flush drain). So capture and forwarding are intact; the gap is specifically mid-run delivery while the session sits paused in the loop — consistent with Ruby block-buffering stdout on a pipe (~8KB buffer that a few fizzbuzz lines never fill), with the flush only happening at exit.Why it matters: the outputMarker was added in PR #254 with the comment "iteration 1's puts — the loop breakpoint re-arms, so later output isn't guaranteed", i.e. iteration 1 was expected to be captured mid-run. Either that expectation regressed at some point, or it was only ever true on Linux/CI. Unknown since when — the soft cell can't fail a build, so nobody was looking.
Possible directions:
STDOUT.sync = true(or$stdout.sync) in the rdbg launch path so debuggee output streams instead of buffering, orRuled out: the #237 redaction hook (session-manager-core handleOutput) — it transforms events that arrive and cannot drop them; the missing marker means the event never arrived, and the arrival path (adapter stdio forwarding, proxy) is untouched by #237. The same hook captured all 17 entries in the direct repro.
Environment: Windows 11, Ruby 3.4 + rdbg, main @ 8c5c2db.