[matt-edmondson]

Fixes #95

What was wrong

AsyncProcessStreamReader reads stdout and stderr in two independent loops, and each loop called its delegate from its own read continuation. So onStandardOutput and onStandardError could run inside each other on different thread-pool threads. If both delegates added to one List<string> (the most natural way to capture a command's whole output), lines disappeared with no exception.

Change

This is option 1 from the triage: serialise delivery.

• AsyncProcessStreamReader holds one Lock per run and takes it around each delegate call. The two pipe reads still run concurrently. Only the hand-off to the caller is serialised, and each stream's chunks still arrive in the order they were written.
• The OutputHandler XML docs now state the contract: the two actions never run at the same time, so they can share state without locking.

A caller whose delegates already take their own lock is unaffected, apart from a lock that is now redundant.

Test

ExecuteAsyncShouldNeverRunTheStandardOutputAndStandardErrorDelegatesAtOnce interleaves 5,000 lines on each stream into a single non-thread-safe List<string> through both delegates, five times over. On every attempt it asserts that:

• the delegates never overlap,
• all 10,000 lines arrive,
• each stream's lines are in order.

It is skipped (Assert.Inconclusive) on Windows, like the neighbouring shell-based test, because the code it covers is platform independent.

• With the fix reverted, the test fails on Assert.AreEqual(0, overlaps).
• With the fix, the full suite passes on Linux/net10.0: 64 passed, 2 skipped (the existing elevation skips), 0 failed.

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
2 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