Repository navigation
bug: LimitOverrunError in _receive_loop() crashes connection without recovery #62
Description
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.
Activity
PsiACE commentedon Feb 7, 2026
#59
is this good for you?
clementsirieix commentedon Feb 9, 2026
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 commentedon Feb 9, 2026
emmm, That sounds reasonable. 0.8.0 includes #59; you can bump to it first to reduce the error.
fix: recover from oversized messages in _receive_loop (Issue agentcli…
koriyoshi2041 commentedon Mar 6, 2026
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(andValueErrorfrom 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.