multi-runtime on Dependabot's #1618 (root bun.lock, @fastify/static 10.1.3 → 10.1.4 — nothing near zlib) went red on the Linux bun leg with the suite otherwise green:
(fail) gzip keeps the event loop turning (#1540) > compress yields to a 1 ms interval while the body encodes
error: gzip compress at level 9 finished in 49.1 ms, under the 50 ms the tick assertion needs to mean anything — grow the fixture, never lower the floor.
The test's own precondition tripped, and it tripped the way the message anticipates. CompressionLiveness.test.ts sizes one 48 MiB fixture for all four legs and asserts each call takes at least MINIMUM_WORK_MS = 50 before it counts ticks; the header records 135 ms for gzip level 9 on the author's machine. On the Linux runners the same leg reads 123–128 ms in the two develop runs before this and 49.5 ms on the #1618 run — every leg in that run was ~2.5× faster (zstd compress 226 vs 375 ms, gunzip 139 vs 206–241 ms), so that was a faster runner class, not a slower one. The floor sits inside the spread of the fastest leg, which makes it a coin toss on a fast runner; the other three legs keep 2.4–4.5× headroom there.
Growing everything is not an option: zstd at level 22 has a cliff — measured here on Bun 1.4.2, 48 MiB compresses in 0.26–0.38 s, 96 MiB in 3.7–5.4 s and 128 MiB in 5.2–5.4 s (the ultra levels run a 128 MiB window), which is the 5 s per-test cap. gzip scales gently: 48 MiB 139–186 ms, 128 MiB 314–475 ms, 160 MiB 557–616 ms, 192 MiB 692–711 ms.
Proposed
One 160 MiB fixture for the gzip compress leg and both decompress legs (the decode legs produce their frame at the default level, where zstd has no cliff), and the zstd level-22 compress leg keeps 48 MiB as a subarray prefix of the same buffer — same data, no second allocation. On the fastest runner observed that puts the gzip leg at ~165 ms (3.3× the floor, the margin the header itself treats as safe) and leaves the heaviest test at ~0.9 s locally with an RSS of ~520 MiB for the file. The header's numbers move with it, and the CI spread goes in as the reason a local measurement is not the margin.
multi-runtimeon Dependabot's #1618 (rootbun.lock,@fastify/static10.1.3 → 10.1.4 — nothing near zlib) went red on the Linux bun leg with the suite otherwise green:The test's own precondition tripped, and it tripped the way the message anticipates.
CompressionLiveness.test.tssizes one 48 MiB fixture for all four legs and asserts each call takes at leastMINIMUM_WORK_MS = 50before it counts ticks; the header records 135 ms for gzip level 9 on the author's machine. On the Linux runners the same leg reads 123–128 ms in the twodevelopruns before this and 49.5 ms on the #1618 run — every leg in that run was ~2.5× faster (zstd compress 226 vs 375 ms, gunzip 139 vs 206–241 ms), so that was a faster runner class, not a slower one. The floor sits inside the spread of the fastest leg, which makes it a coin toss on a fast runner; the other three legs keep 2.4–4.5× headroom there.Growing everything is not an option: zstd at level 22 has a cliff — measured here on Bun 1.4.2, 48 MiB compresses in 0.26–0.38 s, 96 MiB in 3.7–5.4 s and 128 MiB in 5.2–5.4 s (the ultra levels run a 128 MiB window), which is the 5 s per-test cap. gzip scales gently: 48 MiB 139–186 ms, 128 MiB 314–475 ms, 160 MiB 557–616 ms, 192 MiB 692–711 ms.
Proposed
One 160 MiB fixture for the gzip compress leg and both decompress legs (the decode legs produce their frame at the default level, where zstd has no cliff), and the zstd level-22 compress leg keeps 48 MiB as a
subarrayprefix of the same buffer — same data, no second allocation. On the fastest runner observed that puts the gzip leg at ~165 ms (3.3× the floor, the margin the header itself treats as safe) and leaves the heaviest test at ~0.9 s locally with an RSS of ~520 MiB for the file. The header's numbers move with it, and the CI spread goes in as the reason a local measurement is not the margin.