mirror of
https://github.com/badlogic/pi-mono.git
synced 2026-11-05 23:37:25 +00:00
f6278a472e
`JsonRpcLineReader.readStdout` (used by the stdio transport and by `PipeTransport`) appended every stdout chunk to the buffered bytes with `Buffer.concat`, then searched the whole buffer from the start for a newline. A large message arriving in many chunks was therefore copied and scanned again on every chunk. A 12 MiB tool result in 64 KiB chunks took about 350 ms just to frame. Now the reader keeps the bytes of an incomplete message as a list of chunks, with a running byte count, and searches only the new chunk for a newline. When the newline arrives, the chunks are joined once. A line that fits inside a single chunk is sliced directly. The rest is unchanged: the `maxMessageBytes` limit (now checked against the running count), CRLF and blank-line handling, errors for invalid JSON and oversized messages, and the incomplete-message error in `end()`. Testing: - New `packages/mcp/test/lines.test.ts`: - a 1 MiB message fed in 4 KiB chunks calls `Buffer.concat` once (fails on the old code); - a mixed input of multi-byte UTF-8, CRLF, blank lines, an invalid line and several messages gives the same results at every chunk size from 1 byte to the whole input; - reading recovers after an oversized message; - a message without its newline is reported at the end. - `test/lines.test.ts`, `test/stdio.test.ts` and `test/pipe.test.ts` pass. `npm run check` passes. - Micro-benchmark, one message fed in 64 KiB chunks: - before: 1 MiB 5.4 ms, 4 MiB 49.9 ms, 12 MiB 348 ms; - after: 2.2 ms, 7.9 ms, 21.6 ms. Fixes #11761 Requested by @badlogic Co-authored-by: triagent <triagent@localhost> |
||
|---|---|---|
| .. | ||
| agent | ||
| ai | ||
| chord | ||
| codemode | ||
| coding-agent | ||
| durable | ||
| env | ||
| evals | ||
| mcp | ||
| schema | ||
| telemetry | ||
| tui | ||