Read the opening of an agent's answer, not all of it, when testing a connection

[kevin9327]

Register an agent that streams its answer — a Bot working through a document, a model writing slowly
— and press Test connection. The form sits there for the full fifteen seconds and then says:

The agent started answering and the connection broke.

Nothing broke. The agent had already answered correctly: RUN_STARTED was the first thing it wrote.
The person registering it is now looking at their own service, which is fine.

Measured, against a real Bun.serve agent on loopback that writes its events and then keeps
streaming (a kilobyte every 20ms, the way a model streams), with the timeout cut to 3s so the probe
is quick:

before: took 3016ms  { "ok": false, "status": 200,
                       "reason": "The agent started answering and the connection broke." }
after:  took  237ms  { "ok": true, "events": [ "RUN_STARTED" ], "status": 200 }

Why

server/src/agents/connection-test.ts has the right idea written down beside the constant:

/** Enough of the stream to prove it is an agent. Reading it all could mean reading a whole reply. */
const MAX_BYTES = 8_000;

and then reads it all:

body = (await response.text()).slice(0, MAX_BYTES);

response.text() reads a body to its end, so the cap was applied to a string this process had
already taken in full. The check therefore took as long as the agent's run, not as long as its
answer — and when that outlasted AbortSignal.timeout, the abort came back through text() as a
rejected read, into the catch written for a connection that really did drop.

That catch is why the sentence is the one above rather than the timeout one: the request itself had
succeeded, so it is the body read that aborts, and 200 is already on the result.

The fix

Read from response.body until MAX_BYTES is reached, then cancel the rest. Counted in bytes, which
is what the constant is named in and what a chunk off the wire is measured in. The chunk that crosses
the cap is kept whole rather than cut at it — one read past the cap at most, and a cut through a
multi-byte character would put a replacement character in the middle of a line the scan is about to
read.

The cancel is in a finally, because the agent is very likely still writing and nothing is going to
read the rest: leaving it open holds a socket into somebody's agent for as long as that run cares to
go on.

Measured

bun test server/tests/agent-connection-live.test.ts

• Against origin/main with only the new test applied: 10 pass, 1 fail. The new case
  (is reported as working, without waiting for it to finish) takes 3008ms and returns
  ok: false. Whole file: 3.28s.
• With the change: 11 pass, 0 fail. Whole file: 345ms.

The ten cases that were already in that file are the pin, and they pass before and after. They are
the ones that would catch an over-correction, because they are all about reading the body correctly:
a real @copilotkit/aimock agent reporting RUN_STARTED/RUN_FINISHED, a run that starts and never
finishes, an agent answering RUN_ERROR, a stream carrying a tool call, a redirect that is followed,
a redirect that is refused, a redirect loop, and three unreachable addresses.

Also run, all green:

• bun test server/tests/agent-endpoint.test.ts server/tests/agent-test-connection-headers.test.ts server/tests/agent-routes.test.ts — 111 pass, 0 fail
• bun run --filter server typecheck — exit 0
• bunx biome check on both changed files — clean

Note on the CHANGELOG

A deployment behaves differently afterwards, so there is an entry. It goes at the top of
## Unreleased, the same one line every entry goes at, so it will conflict with any other PR open
against that anchor. Happy to rebase whenever it suits you.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.