fix(bench): treat a Next build by the wrong bundler as stale, and let the compile finish - #17
Conversation
… the compile finish
prepare-next-benchmark.sh rebuilt .next/ only when route.ts was newer than
route.js. The switch to `next build --webpack` changed next.config.ts and
package.json and left route.ts alone, so a five-day-old turbopack .next/
passed as fresh, was staged, compiled for eight minutes, and killed the
daemon at preload:
Error: Failed to load chunk server/chunks/[externals]__0l8ei7u._.js
from runtime for chunk server/app/api/benchmark/route.js
Freshness now considers every input that shapes the bundle (route.ts,
layout.tsx, next.config.ts, package.json, package-lock.json) and treats a
`[turbopack]_runtime.js` in the output as stale regardless of mtime; the
build is preceded by removing .next/ so a bundler switch cannot leave mixed
output; and the bundler is asserted after the build, so the failure lands in
seconds rather than one full Perry compile later.
Separately, the script's own timeout (1200 s) was shorter than the
compile_timeout_seconds (1800) it writes into the daemon config, so on a
loaded host it reported "Timed out" with the daemon mid-compile and entitled
to continue. Default raised to 2700 s.
Claude-Session: https://claude.ai/code/session_01UZJbhb2FTuakurTHPAKQgd
|
Warning Review limit reachedNext included review available in 46 minutes. View limit detailsLimit details: You’ve used the included review currently available. Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. Review configuration: ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Free Run ID: 📒 Files selected for processing (1)
ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Free Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe benchmark preparation script now allows longer compilation, detects stale or Turbopack-generated ChangesBenchmark preparation
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This localized script change improves benchmark fixture freshness checks and allows sufficient time for compilation; no actionable merge-blocking risk remains after normal checks and review. Note 🎁 Summarized by CodeRabbit FreeYour organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/settings/billing. Comment |
The script wrote compile_timeout_seconds = 1800 into the generated config with no way to change it. On a host busy with other Perry builds (load average 56) the ~8-minute compile exceeded it and the daemon reported: perry compile terminated for deployment next-bench: wall time exceeded 1800 seconds COOP_NEXT_COMPILE_TIMEOUT now sets it; COOP_NEXT_PREPARE_TIMEOUT defaults to that plus 900 s so the outer limit can never undercut the inner one. Claude-Session: https://claude.ai/code/session_01UZJbhb2FTuakurTHPAKQgd
cc11d88 to
3b70771
Compare
1 participant
Three defects in
prepare-next-benchmark.sh, all found by running #12's fixture on a developer machine rather than a clean runner. None can show up in CI, which builds from an empty checkout; each cost a full Perry compile before reporting.1. A turbopack
.next/passed the freshness checkThe rebuild condition was
route.ts -nt route.js. #12's switch tonext build --webpackchangednext.config.tsandpackage.jsonand leftroute.tsalone, so a five-day-old turbopack build was judged current, staged, compiled natively for ~8 minutes, and then killed the daemon at preload:— exactly the computed-require failure #12's config change exists to prevent, reproduced by a stale artifact of the old configuration. The daemon dies on one app, so it looks nothing like perry#8546 until you check the bundler.
Now: freshness considers every input that shapes the bundle (
route.ts,layout.tsx,next.config.ts,package.json,package-lock.json); a[turbopack]_runtime.jsin the output marks it stale regardless of mtime;.next/is removed before a rebuild so a bundler switch cannot leave mixed output; and the bundler is asserted after the build, so the wrong one fails in seconds, not a compile later.2. The script's timeout was shorter than the compile timeout it configures
COOP_NEXT_PREPARE_TIMEOUTdefaulted to 1200 s while the script writescompile_timeout_seconds = 1800into the daemon's runtime config. On a loaded host the outer limit fired with the daemon mid-compile and still entitled to continue:Timed out after 1200s preparing the Next benchmark fixture.3. The compile budget itself was not adjustable
With the outer limit fixed, the next run died at the inner one:
perry compile terminated for deployment next-bench: wall time exceeded 1800 seconds— the same ~8-minute compile, on a host with a load average of 56 from other Perry builds.compile_timeout_secondswas a literal in the generated config.COOP_NEXT_COMPILE_TIMEOUTnow sets it (default unchanged at 1800), andCOOP_NEXT_PREPARE_TIMEOUTdefaults to that plus 900 s, so the outer limit is derived from the inner one and cannot undercut it again.Verification
bash -nclean.mainat ci: exercise and measure the real Next.js app in the Linux proof #12 on this machine; rebuilding from a removed.next/produced webpack output (webpack-runtime.js, emptychunks/) that the daemon accepted as a compile input.https://claude.ai/code/session_01UZJbhb2FTuakurTHPAKQgd