ReviewOS's page-serving process repeatedly reaches its configured 2 GiB cgroup hard limit and is OOM-killed, terminating active smart-HTTP Git transfers. HQ's Mac runner receives curl 56 / OpenSSL unexpected EOF, early EOF and invalid index-pack output before any native acceptance steps.
Observed on deployed source 541c680, with Stacks 0.75.217 / STX 0.2.574 / Bun 1.4.2. Kernel events identify the web service at 15:31 and 15:48 UTC on October 29; its memory peak reaches exactly 2,147,483,648 bytes. The separate API service remains active. Later web restarts continue.
Affected consumer runs:
Both deployed Bun 1.4.2 and local Bun 1.4.4 hold a 50 MiB writer at the pipe when its reader stops, for both Node child_process and native Bun.spawn. That measurement does not support treating the historical stdout buffering defect as the current cause.
Investigate retained data / allocation growth in the web-serving path and repair the responsible first-party source package. Keep the hard memory bound and normal transport; protocol overrides, retry loops, larger limits and scheduled garbage collection are not acceptance.
Acceptance: representative sustained page/code browsing and fresh normal runner checkouts remain within the configured bound, with no OOM restart, truncated Git transfer or cross-account response/cache leak. Preserve cancellation and streaming behavior. Any temporary diagnostics must be removed after verification.
Related: https://github.com/stacksjs/hq.training/issues/346, https://github.com/stacksjs/hq.training/issues/318, https://github.com/stacksjs/hq.training/issues/366, https://github.com/stacksjs/hq.training/issues/368.