[matt-edmondson]

A LineOutputHandler kept its line-splitting state, outputBuffer and errorBuffer, on the instance. When two runs shared one handler and overlapped:

• The second run's Reset() threw away the first run's partial line.
• Both runs then appended to the same StringBuilder from different threads. Their text came out joined ("BBBBAAAA" | "BBBB"), and the unsynchronised writes could corrupt the builder.

This takes the per-run fix the issue prefers:

• OutputHandler gains internal virtual OutputHandler CreateRunHandler() => this.
• LineOutputHandler overrides it to return a new LineOutputHandler with the same delegates and encoding, and empty buffers.
• RunAsync feeds each run to outputHandler.CreateRunHandler(), so every run has its own line state and nothing one run leaves behind reaches another.

Reset() is still called on the run handler, so a stateful handler that returns itself keeps today's behaviour. The public API is unchanged.

The delegates are still serialised per run, by the existing deliveryLock, not across runs. I chose not to take a handler-wide lock: a delegate that starts a nested run on the same handler would deadlock on it. OutputHandler's remarks now say the never-at-the-same-time guarantee covers one run, and that state shared between concurrent runs needs its own lock, as the repro's lock (lines) already does.

Tests

• New LineOutputHandlerSharedByOverlappingRunsShouldKeepEachRunsLinesApart: run A prints AAAA, waits, then finishes its line. Run B starts on the same handler while A is mid-line. The test expects exactly AAAAAAAA and BBBBBBBB.
  • With the library change stashed, it fails.
  • With the change, it passed 5 out of 5 repeated runs.
• ReusedLineOutputHandlerShouldDropTheLineARunWhoseCallbackThrewLeftUnfinished had a precondition that the failed run's partial line sat in the shared handler's buffer. That partial line now lives in the run's own handler, so the precondition now asserts that the shared buffer is empty. The test's actual check, that the next run starts clean, is unchanged.
• Full suite: 67 tests, all pass (2 skipped as before, elevation-only). Release build succeeds for every target framework.

Related: #129 (bare CR delivery) touches LineOutputHandler buffering too, but in ProcessDataByLine, not where the buffers are owned. Whichever lands second should rebase cleanly. #125 is a separate cancellation-timing issue and is not addressed here.

Fixes #130

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
4 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud