ExecuteAsync hangs forever (and leaves the child blocked) when the output handler throws or a strict encoding hits a decode error

[matt-edmondson]

What's wrong

When a read faults, AsyncProcessStreamReader.Start breaks out of its read loop (RunCommand/AsyncProcessStreamReader.cs:74-77) and stops reading both pipes. A read faults when the handler callback throws, or when the handler's Encoding uses throwOnInvalidBytes: true, a case the code explicitly supports ("carries a decode error out to the caller").

RunCommand.cs:484-485 then awaits:

await Task.WhenAll(outputReader.Start(ct), process.WaitForExitAsync(ct));

WhenAll doesn't complete until the process exits, and nothing kills the process. Once the child writes more than the pipe buffer holds (≈64 KB on Linux, less on Windows), it blocks on write() forever. The call never returns, and the exception is never surfaced.

Reproduction (Linux, net10.0)

• new OutputHandler(s => throw new InvalidOperationException()) with sh -c "echo first; sleep 0.5; head -c 1000000 /dev/zero" → the task is still pending after 10 s, and the head process is still alive.
• encoding: new UTF8Encoding(false, throwOnInvalidBytes: true) with sh -c "printf '\377\n'; sleep 0.5; head -c 1000000 /dev/zero" → the task is still pending after 10 s.

Suggested fix

In RunAsync, observe the reader task on its own. If it faults, call the existing TryKill(process) (killing the whole process tree), then await the exit and rethrow the read exception. For example:

Task read = outputReader.Start(ct);
try { await read; } catch { TryKill(process); throw; }
await process.WaitForExitAsync(ct);

Acceptance criteria

Both repros throw the handler or decode exception promptly (well under a second after the fault), and no child process is left running.

[matt-edmondson]

Triage

• Category: Bug
• Priority: High. ExecuteAsync never returns, the exception that caused it is never seen, and the child process is left blocked on a full pipe. Two triggers cause it: a handler that throws, and a strict Encoding, which the code documents as supported. There is no workaround short of making sure the handler never throws.
• Area / suggested assignee: RunAsync completion (RunCommand.cs:484-485) and the fault path in AsyncProcessStreamReader.Start. Maintainer: @matt-edmondson.
• Duplicates: None. Related:
  • Reader spins at 100% CPU for the rest of the run once a command closes stdout or stderr but keeps running #90 is the same read loop, but a different defect: it busy-spins at end of stream instead of stopping on a fault.
  • LineOutputHandler never delivers a final line that has no trailing newline, and leaks it into the next run #88 is about the OutputHandler completion contract.
• In progress: No open PR fixes this. Read each output stream to end of stream, not just until exit #87 ("Read each output stream to end of stream, not just until exit", fixes Output is silently truncated when a command writes more than about 8 KB that is still unread when it exits #84) rewrites Start into a ReadToEnd loop for each stream, and awaits both through DrainOrAbandon. Once one stream's loop has faulted, nothing reads that pipe any more. The child can still block on write(), and WaitForExitAsync can still wait forever. So Read each output stream to end of stream, not just until exit #87 is unlikely to fix this on its own, and it conflicts with any fix made here.

Next steps: Land #87 first, then build this fix on its ReadToEnd structure. When a read loop faults, call TryKill(process) so the whole process tree is killed, then await exit and rethrow the original exception. Add both repros as tests, with a timeout, and assert that no child process is still alive afterwards.

---

Generated by Claude Code