mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-25 17:45:53 +01:00
Priya RamanandPaperclip
a33d2aaae9
The duplex readiness gate checked the pre-READY buffer cap with Buffer.byteLength, which is O(n) in the buffer length. A provider that controls the chunk size could send many small newline-less chunks, so the per-chunk byte scan made the pre-READY window quadratic in the bytes received. This was a CPU-exhaustion path on channel open. Gate on buffer.length, the UTF-16 code-unit count, which is O(1). The UTF-8 byte length is greater than or equal to the UTF-16 code-unit count for every string, so the check never fires before the byte cap is truly exceeded. It can fire late by at most a factor of 3, so peak buffer memory stays bounded near 3 MB. The failure reason and every other gate behavior stay unchanged. Add a test that feeds many small newline-less chunks past the cap and asserts the gate finishes with protocol contamination. Correct one telemetry README sentence. Counters carry no dimension labels; fallback_reason and loss_class fold into the counter metric name. The full closed dimension set rides only the spans and the transport event. Co-authored-by: Paperclip <noreply@paperclip.ing>