bug: LimitOverrunError in _receive_loop() crashes connection without recovery

[clementsirieix]

Summary

When a message exceeds the buffer limit, the _receive_loop() (acp/connection.py:151) method raises an unhandled LimitOverrunError which propagates up and terminates the entire connection, meaning that the agent becomes unresponsive.

Reproduction steps

Perform a request with a line exceeding 64kb, something like: go to unsplash to get a free picture of several MB, convert it into a base64 string, and use it your prompt.

Expected result

Large lines should be handled gracefully.

Actual result

The agent crashes.

Versions / environment

SDK 0.7.1, Zed, Mistral-Vibe ACP v2.0.2

Logs & screenshots

Open to submitting a fix?

• I’m willing to open a PR for this bug.

[PsiACE]

#59

is this good for you?

[clementsirieix]

Thanks for the quick reply, I think this change will reduce the risk of the error occurring.
That said my expectation is that I would not get a crash for that kind of error, instead I would like to see an error, and still be able to send an improved prompt. wdyt?

[PsiACE]

That said my expectation is that I would not get a crash for that kind of error, instead I would like to see an error, and still be able to send an improved prompt.

emmm, That sounds reasonable. 0.8.0 includes #59; you can bump to it first to reduce the error.

[koriyoshi2041]

I ran into this exact issue while working with the SDK. The buffer increase in #59 (v0.8.0) helps reduce the frequency, but as @clementsirieix pointed out, a crash on oversized messages is still not ideal — the connection should recover gracefully.

I submitted #72 which catches LimitOverrunError (and ValueError from incomplete reads) inside _receive_loop(), discards the oversized line, logs a warning, and continues processing the next message. This way the connection stays alive and the agent remains responsive, even if one message exceeds the limit.

The approach is intentionally minimal: catch, log, continue. No retry logic or complex error propagation — just don't let one bad message kill the whole connection.