build(docs): stop emitting the 348 MB of server source maps the OOM-killed build was paying for

[os-zhuang]

Production docs deploys have been OOM-failing all day (exit 137, Vercel errorCode: "out_of_memory", 4-core/8192 MB build machine). This suppresses 348 MB of server source maps that nothing in production reads.

Where the build actually dies

Every failing log places the kill between Creating an optimized production build ... and Compiled successfully, with zero output in between:

11:31:03.206 Creating an optimized production build ...
11:42:26.615 ERROR ... exited (137) <- 11m23s of silence

So the peak is the Turbopack compile phase. The build never reaches Collecting page data / Generating static pages — which retires the prerender-based attribution in #12683, and with it the 403 build-time OG PNGs and 403 markdown routes as suspects. They are generateStaticParams work in a phase the process dies before.

It also explains why neither knob already in the tree reaches this: experimental.cpus: 2 bounds static-generation workers that have not spawned yet, and --max-old-space-size bounds V8 while Turbopack allocates from Rust outside it. Both confirmed by measurement below — which is #12683's own finding, now with the mechanism attached.

Measured (local cold build, all 403 pages, peak single-process RSS)

config	peak	compile	verdict
before	5191 MB	22.6s	—
turbopackSourceMaps: false	4757 MB	19.5s	✅ shipped
turbopackScopeHoisting: false	4806 MB	19.1s	noise — retired
--max-old-space-size=2048	4734 MB	18.0s	noise — retired
turbopackFileSystemCacheForBuild: true	4779 MB	22.2s	noise — retired
+ turbopackMinify: false	3785 MB	16.2s	⚠️ rejected, see below
includeProcessedMarkdown: false	—	—	build fails (getLLMText)

The negative rows are recorded so they are not re-tried.

Why turbopackMinify: false is not in here

It takes another 972 MB off the peak, but client JS goes 5.8 MB -> 16 MB (+176%) — a cost every reader pays on every visit, to save memory in a machine they never touch. Confining it to the server side (where the memory is: 589 MB of server chunks vs 5.8 MB client) is not on offer: experimental.serverMinification is read only by dist/build/webpack-config.js and never on the Turbopack path.

What this does not claim

It buys margin; it does not prove the ceiling is cleared. The measurement is macOS/arm64 against a Linux/x86_64 container where the same phase measured 7.6 GB (#12683) vs 4.7 GB locally — the ratio is the transferable part, and −8.4% onto 7592 MB leaves ~15% headroom, which is thin. #12683's option A (larger build machine) is untouched by this PR and remains the answer if the next production build still dies. Merging this first costs one build cycle to find out.

Secondary signal worth watching: Vercel spends 11 minutes compiling what takes 20s locally. A 4-vs-10 core gap does not explain 30x — the rest is thrashing near the ceiling, so a successful build should also come back much faster.

Verification

Merge, then:

curl -s https://objectstack.ai/ | grep -o 'data-dpl-id="[^"]*"'

Any id other than dpl_2nfWjGjSwZjakVEmUG1kBWD6697r means the outage is over.

Also corrects #12698

#12698's action 2 ("fix the Ignored Build Step") rests on a misreading. The project's rule is if [ "$VERCEL_ENV" == "production" ]; then exit 1; else exit 0; fi — exit 1 = build, exit 0 = skip — so production always builds and Preview always skips. The Canceled by Ignored Build Step on PR #12684's head was that PR's Preview being skipped, as intended. Pushes to main do trigger production builds; they were failing, not skipped. No dashboard change is needed there.

Refs #12711, #12683, #12698

🤖 Generated with Claude Code