Summary
When a response stream drops mid-flight, the CLI surfaces submit_error: Error: 500 ERROR even though nothing in the request path ever returned a 500. Tracing a reproduction end to end: POST /alpha/generate returned HTTP 200, the upstream provider fetch returned HTTP 200, content type text/event-stream, first chunk arrived at ~2-3s TTFT — and then the stream terminated with 0 input / 0 output tokens recorded.
The 500 is fabricated by our own error formatter. Users read it as a server outage and open support tickets for an incident that isn't happening.
Expected Behavior
The error should describe what actually happened — the response stream ended before completion — and must not name an HTTP status code that was never returned. If a status is shown it should be the one the API actually sent.
Actual Behavior
After the retry budget is exhausted (7 attempts with backoff), the CLI prints:
submit_error: Error: 500 ERROR
Type "continue" to try again. If the issue persists, contact support: ...
The trailing ERROR is the exception message itself. transportError() builds a TransportError from the stream body, and when that body is empty or unparseable the message degrades to the literal string ERROR. The submit path then prefixes an unrelated 500.
Stack from a captured failure:
TransportError: ERROR
at transportError (.../dist/cli.mjs)
at consumeStream (.../dist/cli.mjs)
at async Object.complete (.../dist/cli.mjs)
at async callModelWithRetry (.../dist/cli.mjs)
at async agentLoop (.../dist/cli.mjs)
Steps to reproduce the issue
- Start a session and drive the conversation until each request payload is several MB (large tool outputs — build logs, installs, file dumps — do this quickly).
- Send a prompt.
- The stream opens, delivers a first chunk, then aborts roughly 10s in with no usage recorded.
- The CLI retries 7 times and then reports
submit_error: Error: 500 ERROR.
Any upstream mid-stream abort reproduces the mislabelling; the oversized payload is just a reliable way to trigger one.
Command Code Version
1.32.1
Operating System
Windows
Additional context
Same user-visible symptom as #597, where the reporter also noted token consumption was 0 — consistent with a stream that opens and aborts before emitting usage. The message text varies with what the upstream returns (500 ERROR, 500 Network connection lost), but the invented 500 prefix is common to both.
The oversized-payload trigger has its own root cause: #756.
Summary
When a response stream drops mid-flight, the CLI surfaces
submit_error: Error: 500 ERROReven though nothing in the request path ever returned a 500. Tracing a reproduction end to end:POST /alpha/generatereturned HTTP 200, the upstream provider fetch returned HTTP 200, content typetext/event-stream, first chunk arrived at ~2-3s TTFT — and then the stream terminated with 0 input / 0 output tokens recorded.The
500is fabricated by our own error formatter. Users read it as a server outage and open support tickets for an incident that isn't happening.Expected Behavior
The error should describe what actually happened — the response stream ended before completion — and must not name an HTTP status code that was never returned. If a status is shown it should be the one the API actually sent.
Actual Behavior
After the retry budget is exhausted (7 attempts with backoff), the CLI prints:
The trailing
ERRORis the exception message itself.transportError()builds aTransportErrorfrom the stream body, and when that body is empty or unparseable the message degrades to the literal stringERROR. The submit path then prefixes an unrelated500.Stack from a captured failure:
Steps to reproduce the issue
submit_error: Error: 500 ERROR.Any upstream mid-stream abort reproduces the mislabelling; the oversized payload is just a reliable way to trigger one.
Command Code Version
1.32.1
Operating System
Windows
Additional context
Same user-visible symptom as #597, where the reporter also noted token consumption was 0 — consistent with a stream that opens and aborts before emitting usage. The message text varies with what the upstream returns (
500 ERROR,500 Network connection lost), but the invented500prefix is common to both.The oversized-payload trigger has its own root cause: #756.