alexeysophia 80dcef5044 fix: large base64 attachments on /v1/responses crash the gateway with heap OOM (#126017) ...

* fix(media): stop canonicalizeBase64 allocating one cons-string node per char

Per-character append built a rope of ~25 bytes per input character, all
live until the final join — a 20 MB base64 attachment transiently needed
~700-900 MB of heap and OOM-crashed the gateway on POST /v1/responses.
Validate in the same single pass but collect contiguous non-whitespace
runs as slices; already-canonical input is returned unchanged with zero
allocations. Measured: 15 MiB attachment 659 MB -> 0 MB transient heap,
4.3 s -> 0.2 s.

* fix(media): bound canonicalizeBase64 cleanup memory by input length

Review found the run-slicing cleanup unbounded for adversarial input:
alternating data characters and whitespace retains one slice object per
run (measured 421 MB of heap for an 8 MiB payload shredded to one run
per character). Replace the run collection with a single output buffer
materialized on the first whitespace and filled in the same validating
pass: canonical input still returns unchanged with zero allocations, and
any whitespace shape now costs at most one buffer bounded by the input
length (measured 0 MB heap delta, 210 ms for the same shredded payload).
Adds the many-short-runs regression test the review asked for, guarding
both heapUsed and arrayBuffers.

* refactor(media): condense canonicalizeBase64 invariant comment

Review asked for the repository's 1-3-line invariant form: keep why the
buffer is lazy and bounded, drop the implementation-history narration.

* chore: retrigger CI (flaky gateway-server shard)

* test(media): update base64 memory comment

Punchcard-Session: frost-cedar-willow-ae

---------

Co-authored-by: Vincent Koc <vincentkoc@ieee.org>

2026-08-20 01:11:37 +08:00

..

src

fix: large base64 attachments on /v1/responses crash the gateway with heap OOM (#126017)

2026-08-20 01:11:37 +08:00

package.json

…