fix(cloud-agent-next): retry attachment downloads and hide raw stream errors

[maphew]

Problem

Pasting an image into a Kilo Cloud Agent thread can silently fail: the wrapper's attachment materialization (services/cloud-agent-next/wrapper/src/session-bootstrap.ts) catches any error while fetching the presigned R2 attachment URL inside the sandbox and interpolates the raw error into a synthetic text part:

attachment a7393f97-c6bf-4c1f-9fec-2bbb11987962.png could not be retrieved (undefined is not a function)

The (undefined is not a function) text is a raw JS TypeError leaking into the user-visible transcript. It matches a known class of Bun Web Streams bugs where reading a fetch() Response.body whose bytes arrive after the response head throws exactly TypeError: undefined is not a function (oven-sh/bun#34302, oven-sh/bun#28952, oven-sh/bun#28953). The failure is intermittent (network-latency dependent), there is no retry, and a transient failure permanently drops the image from the prompt. The agent then "carries on" without the image.

Repro evidence: iterating a delayed-body Response.body on Bun 1.3.12 fails 100/100 with the identical message; the failure disappears when the body is read via getReader().read() or arrayBuffer().

Fix

• Retry transient attachment-download failures — up to MAX_ATTACHMENT_DOWNLOAD_ATTEMPTS (3) attempts with short backoff (250ms, then 750ms). Non-2xx 429/5xx responses and fetch/read/timeout errors are retried; 4xx (except 429) and size-cap overflows are permanent.
• Use a buffered read on retry — retries re-fetch and read the body with response.arrayBuffer() (the workaround Bun's maintainers verified never hits the stream race) when content-length is present and within the 20 MiB cap; otherwise the existing bounded streaming read is used.
• Stop leaking raw JS error text — once retries are exhausted the part reads attachment <name> could not be retrieved (download failed after 3 attempts) and the underlying reason goes to the wrapper log instead of the transcript. Overflow keeps its typed Attachment too large: ... message, and non-retryable HTTP statuses still report HTTP <status>.

Each attachment still degrades independently: one failed attachment never blocks the rest of the prompt.

Tests

• Existing overflow / HTTP-403 / generic-binary / exact-cap cases unchanged (all single-attempt, non-retryable paths).
• Updated the two always-failing transient-error tests to assert the new exhausted-retry message and that 3 attempts were made.
• Added: "retries a transient fetch failure and materializes the attachment on the retry" and "falls back to a buffered read when the streaming read fails mid-transfer".

Fixes #5883

[kilo-code-bot]

Code Review Summary

Status: 2 Issues Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	2
SUGGESTION	0

Issue Details (click to expand)

WARNING

File	Line	Issue
services/cloud-agent-next/wrapper/src/session-bootstrap.ts	1142	Buffered retries throw unbounded body instead of falling back to downloadBounded when content-length is missing/invalid/oversize
services/cloud-agent-next/wrapper/src/session-bootstrap.ts	1278	Caller abort is treated as retryable; sleep/retry omits externalSignal?.throwIfAborted()

Files Reviewed (2 files)

• services/cloud-agent-next/wrapper/src/session-bootstrap.ts - 2 issues
• services/cloud-agent-next/wrapper/src/session-bootstrap.test.ts

Fix these issues in Kilo Cloud

---

_{Reviewed by grok-4.6 · Input: 169.3K · Output: 23.9K · Cached: 705.9K}

_{Review guidance: REVIEW.md from base branch main}