fix(build): bake --max-old-space-size=4096 into compiled full binaries - #3811
Conversation
Compiled binaries ignore DENO_V8_FLAGS at runtime, so the production chart's --max-old-space-size=4096 never reached the release binary: all 19 heap OOMs over 30 days died at V8's ~2 GiB default while the manifest verifiably set 4096 (veryfront-issue-inbox#269). deno compile --v8-flags serializes the flags into the binary trailer, which is the only channel a compiled artifact gets them through. Bake the 4096 MB old-space limit into the full profile, keep the proxy profile on V8 defaults (proxy pods run under a 1536 MiB cgroup limit), and extend the post-compile artifact assertion to fail the build when the flag is missing from the trailer -- checked on the artifact bytes because release builds cross-compile targets CI cannot execute. Verified on the pinned Deno line: a probe compiled with a 3000 MB sentinel reports heap_size_limit 3096 MB regardless of runtime DENO_V8_FLAGS, while the same probe compiled the old way stays at the host default.
📦 Client bundle boundary
A server module in a client graph aborts hydration in the browser. New leaks fail CI; known leaks are tracked in |
|
Warning Review limit reached
Next review available in: 40 minutes Limit details: You’ve used all 1 included review currently available under your plan. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0a398ac7db
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
The artifact guard's failure message wrote an internal tracker reference into CI logs. veryfront-code is a public repository, so those Actions logs are publicly readable, and the identifier points at a private repo. Every issue reference elsewhere in src/ lives in a comment; none is emitted in message text. Keep the message's actionable half -- compiled binaries ignore DENO_V8_FLAGS, so a missing baked flag means the ~2 GiB default heap -- and drop the identifier, which tells a build-failure reader nothing they can act on.
|
@codex review Please review exact head |
|
Codex Review: Didn't find any major issues. 🚀 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
1 participant
Problem
Compiled binaries ignore the
DENO_V8_FLAGSenvironment variable at runtime, so setting--max-old-space-size=4096in the deployment environment never reaches a compiled release binary. A deployment can verifiably set the env var while the process still runs at V8's ~2 GiB default old-space limit and OOMs there.deno compile --v8-flagsis the only channel through which a compiled artifact receives V8 flags: they are serialized into the binary's trailer at compile time and are final (a runtimeDENO_V8_FLAGScannot override them).Fix
--max-old-space-size=4096into the full profile via--v8-flagsincreateCompileArgs(scripts/build/compile-binary.ts). The baked value is the real production heap ceiling; production pods are sized (5 Gi limit) around it.smoke-proxy-memory.sh), and a 4 GiB old-space ceiling would turn GC back-pressure into OOMKills."v8_flags":[...]array (joined baked flags plus the closing]), so an embedded source file that merely contains the quoted flag literal cannot satisfy the check vacuously. Checked on the artifact bytes because release builds cross-compile targets CI cannot execute.Tests
scripts/build/compile-binary.test.ts:--v8-flags=--max-old-space-size=4096; proxy profile emits no--v8-flags.heap_size_limitin the 3000–3256 MB window even with a conflicting runtimeDENO_V8_FLAGS— V8 defaults land near ~2 GiB or ~4 GiB, never ~3 GiB, so the observed limit can only come from the baked flag.--v8-flagsargs serializes the flag into the trailer, verified through the same guard the build uses; this doubles as the empirical proof that the tail-anchored marker matches a real artifact on the pinned Deno line.Verified locally on Deno 2.7.12 (CI pins the same 2.7 line).
Ref: veryfront-issue-inbox#269