Pending send_request futures never resolve when the transport ends (EOF) — load-bearing but unspecified

[SPIKESPIGEL404]

Summary

When a connection's transport reaches EOF (e.g. a ByteStreams peer closes, or the remote process dies), in-flight send_request futures are never resolved — they park forever. Nothing fails them with a transport-closed error, and the behavior isn't documented.

This matters because it is silently load-bearing in AcpAgent: its connect_to races the protocol future against a child monitor, so a dying agent process happens to tear everything down. But any consumer that brings its own transport via ByteStreams (the documented "sockets, pipes" use case) inherits the hang with no warning: an agent that dies mid-request leaves the caller's initialize/session/prompt awaiting forever.

Reproduction

1. Connect a Client over ByteStreams to a process that answers initialize, then exits 300ms later.
2. Send session/prompt (or any request) in that window.
3. The request future never resolves — no error, no timeout — even though the incoming stream ended. (We hit this exactly while replacing AcpAgent with our own spawn + ByteStreams; the fix on our side was re-creating the child-death race externally.)

Ask

Either (preferably both):

1. Fail pending requests on transport end. When the incoming stream terminates, resolve every pending reply with a transport-closed error (and, ideally, have connect_with complete). This matches what users of request/response RPC libraries generally expect, and would make the AcpAgent child-monitor race a redundancy instead of a hidden requirement.
2. Document the current contract on ByteStreams / connect_with: "transport EOF does not fail in-flight requests; callers must race the connection against their own liveness signal" — plus a cookbook example of doing so.

Happy to contribute either — (2) is trivial; for (1) I'd appreciate a pointer on whether failing pending_replies in the incoming actor's end-of-stream path is the intended place.

Environment

• agent-client-protocol 1.0.0 and current main.
• Found while building bitrouter's per-session ACP substrate (feat(acp): per-session ACP substrate (acp serve|prompt) bitrouter/bitrouter#613); our workaround: race the connection future against a child-exit signal and drop it on death.