This field test was against Next.js.
The issue was long-running memory pressure around Image Optimization:
https://github.com/vercel/next.js/issues/54482
The thread described high memory usage when optimized images were generated repeatedly. The original issue had been difficult to pin down because the reports were mostly operational symptoms: memory growth, screenshots, and production behavior.
Scarab Diagnostic Suite surfaced one concrete boundary worth testing:
native image transformation → optimized output buffering → response-size budget
In plain terms, the image optimizer was using Sharp to transform images, then collecting the optimized output with toBuffer().
That means the optimized image output could be fully materialized in memory before the existing response-size budget had a chance to stop it.
The repair candidate is intentionally narrow.
It does not redesign the image optimizer.
It does not change image cache behavior.
It does not stream responses directly to the client.
Instead, it keeps the existing final Buffer return shape used by cache and ETag handling, but changes how the optimized output is collected.
The local patch:
- consumes Sharp output chunk by chunk
- counts optimized output bytes as they arrive
- uses the existing images.maximumResponseBody value as the output budget
- aborts collection with the existing ImageError(413) behavior if the optimized output exceeds that budget
- preserves successful output when the result is exactly within budget
A focused regression test was added for both sides of the boundary:
- output over budget throws ImageError(413)
- output exactly at budget succeeds
Local validation passed across the image optimizer tests, type checks, formatting check, and diff check.
I left a maintainer-facing comment on the issue asking whether this direction would be useful as a PR against canary.
Field Test #008
Project: Next.js
Issue type: image optimization memory/resource pressure
Boundary: native media transform output buffering vs declared response-size budget
Result: narrow local repair candidate and regression test prepared
Status: maintainer direction requested before opening PR
The important part is that Scarab identified a specific resource boundary inside the optimizer path and produced a bounded, testable repair candidate.
Top comments (0)