[piersdd]

Summary

When a transport stream finishes (e.g. subprocess death closes the pipe), the Client's message handling loop spins at 100% CPU indefinitely.

The root cause is the repeat { ... } while true outer loop in Client.connect(transport:) (line 217). When the for try await data in stream loop exits normally on stream EOF, the repeat re-enters connection.receive(), gets an instantly-finishing stream, and loops again — consuming a full CPU core.

The Task.isCancelled check at the top of the repeat body only helps if disconnect() was called externally. On a normal subprocess/transport death, no cancellation is signalled — the stream simply finishes.

Server.swift in this same package does not have this bug — it uses a flat do { for try await ... } without an outer repeat loop.

Fix

Remove the repeat { ... } while true wrapper, matching the Server.swift pattern. The message handling task now:

1. Calls connection.receive() once
2. Iterates the stream with for try await
3. Exits cleanly when the stream finishes (EOF) or an error is thrown

The catch for isResourceTemporarilyUnavailable (which used continue to re-enter the repeat) is also removed. That EAGAIN-style error is a transient I/O condition handled internally by the transport's read loop — it does not surface through the AsyncThrowingStream that receive() returns.

Reproduction

1. Start a Client connected via StdioTransport to a subprocess
2. Kill the subprocess (or let it exit)
3. Observe the Client's task consuming 100% CPU via sample or Activity Monitor

The tight loop shows up as:

Client.connect(transport:) → AsyncThrowingStream.Iterator.next() → repeat

Test plan

• Existing test suite passes (545 tests in downstream consumer, SDK tests unmodified)
• Verified CPU drops from 88–99% to 0% after subprocess death
• disconnect() still terminates the loop correctly (cancels the task)
• Normal message handling unaffected (stream stays open while transport is alive)

[deseven]

Thank you so much, this solved my problem with randomly hanging tests where I run hundreds of tools quickly.

[piersdd]

Rebased onto current main (a0ae212, including #223) so this is mergeable again.

This was already approved, and the July comment from @deseven said it unblocked hanging tests under rapid tool use. Happy to rebase again if needed.

[varun06]

Hi @piersdd, thanks for this PR! I've reviewed it and it looks good to merge.

Could you please rebase it onto the latest main? CI was broken on macOS runners for every PR (a toolchain/SDK mismatch, fixed in #306), so rebasing will pick up the fix and give us a green run. I'll review and merge once it's updated.

This already has an approval, so once it's rebased and green I'll merge it. (Optional: a small regression test, like the one in #275, would be welcome but isn't required.)

If you're no longer able to work on this, no problem: just let us know. If we don't hear back in about two weeks, we may carry the change forward in a new PR, with credit to you.