What causes "Stream read error: {e}" in Hmbown/CodeWhale?

Retry the request — transient transport errors dominate

Stream read error: {e}

Error message

Stream read error: {e}

What it means

On the Antigravity cloud-code route, the HTTP body stream returned an error mid-read (the `Ok(Some(Err(e)))` arm of the chunk read). The client yields this error and returns, ending the stream; unlike the chat route it does not log a source-chain diagnostic here.

Source

Thrown at crates/tui/src/client/cloud_code.rs:179

            );
            bail!("Antigravity cloud-code HTTP {status}: {redacted}");
        }

        let stream_idle_timeout = self.stream_idle_timeout;
        let byte_stream = response.bytes_stream();
        let stream = async_stream::stream! {
            let mut buffer: Vec<u8> = Vec::new();
            let stream_start = std::time::Instant::now();
            let mut last_chunk_at = std::time::Instant::now();
            let mut bytes_received: usize = 0;
            let mut started = false;
            tokio::pin!(byte_stream);

            loop {
                let chunk = match tokio::time::timeout(stream_idle_timeout, byte_stream.next()).await {
                    Ok(Some(Ok(chunk))) => chunk,
                    Ok(Some(Err(e))) => {
                        yield Err(anyhow::anyhow!("Stream read error: {e}"));
                        return;
                    }
                    Ok(None) => break,
                    Err(_) => {
                        yield Err(anyhow::anyhow!(stream_entry::idle_timeout_message(
                            stream_idle_timeout,
                            bytes_received,
                            stream_start.elapsed(),
                            last_chunk_at.elapsed(),
                        )));
                        return;
                    }
                };
                bytes_received += chunk.len();
                last_chunk_at = std::time::Instant::now();
                buffer.extend_from_slice(&chunk);

                loop {

View on GitHub (pinned to 8880682c63)

Solutions

Retry the request — transient transport errors dominate
Check network path and bypass intermediaries if it recurs
If deterministic at the same point, capture request size — an intermediary body-size or time limit may be in play

Defensive patterns

Strategy: retry

Type guard

fn is_stream_read_error(err: &anyhow::Error) -> bool {
    err.to_string().starts_with("Stream read error")
}

Try / catch

match stream.next().await {
    Some(Err(e)) if is_stream_read_error(&e) => {
        backoff().await;
        stream = client.reopen_cloud_code_stream(request).await?;
    }
    Some(Err(e)) => return Err(e),
    other => { /* forward */ }
}

Prevention

Retry transient transport errors on the cloud-code route with backoff
Keep cloud-code sessions short enough to survive proxy connection limits
Bypass intermediaries that cut long-lived SSE connections

When it happens

Trigger: Connection reset or RST_STREAM during the cloud-code SSE body; decompression failure; proxy cutting the long-lived stream.

Common situations: Long agentic cloud-code sessions behind proxies/VPNs; unstable networks; Google-side connection recycling.

Related errors

AI-assisted analysis of Hmbown/CodeWhale@8880682c63 (2026-08-16). Data as JSON: /api/errors/8f5818f479afd543. Report an issue: GitHub.