`handleApplication` 30s timeout aborts a legitimate `next build` (webpack) before it completes

[dawsontoth]

Summary

The on-startup production build must complete within Harper's 30 s handleApplication timeout. A real cold next build (Next.js 16, webpack) does not finish in 30 s, so Harper aborts the component load before the build produces a .next — the app never serves.

This surfaces once you set bundler: webpack to sidestep the Turbopack crash (filed separately): with webpack there's no crash, just a timeout.

Environment

• Harper (harper-pro) 5.1.23, multi-node replicated cluster
• @harperfast/nextjs 2.2.3
• next 16.2.11, React 19 (App Router)
• Component config: '@harperfast/nextjs': { package: '@harperfast/nextjs', bundler: webpack }

What happens

Error: Could not load component '@harperfast/nextjs' for application '<app>' due to:
  handleApplication timed out after 30000ms for @harperfast/nextjs on behalf of <app>

No build error and no crash — the webpack build is still running when Harper's 30 s component-load deadline fires and tears it down. GET / returns 500 for the life of the component.

Root cause

handleApplication runs the full next build inline (build() → withBuildLock → runNextBuild) and must return within the fixed 30 s component-load budget. Even a trivial app's cold Next 16 build exceeds that on the cluster, so the build is aborted every time. Because the abort happens mid-build, no .next/BUILD_ID is ever produced and subsequent restarts repeat the timeout.

Reproduce

1. Minimal Next.js 16 app + @harperfast/nextjs with bundler: webpack.
2. Deploy to a cluster; GET / → 500 "handleApplication timed out after 30000ms".

Impact

Even with the Turbopack crash worked around, the server-side-build model can't complete within the component-load window. Combined with the Turbopack issue, neither bundler can do an on-startup build on a real cluster today.

Possible directions

• Do the build off the handleApplication critical path (e.g. build asynchronously and serve once .next is ready / return fast and mark the component "building"), rather than blocking the component load on a full next build.
• Make the build timeout configurable / much larger for this plugin, and/or persist a completed build so restarts don't rebuild from scratch.
• A dedicated build step / buildOnly at deploy time, then serve prebuilt.

Workaround

prebuilt: true — build .next ahead of time and ship it; the plugin skips building entirely, so there's no build to time out. Verified working on 5.1.23.

Related

• Turbopack "Worker creator already registered" crash (filed separately) — the reason one reaches for bundler: webpack in the first place.
• Multi-thread build race: concurrent next build across worker threads fails with ENOENT on .next/BUILD_ID (server-side deploys 404) #52 build race, Running a build at a runtime with a RocksDB database fails #37 build-vs-RocksDB lock.

[dawsontoth]

Companion issue: #57 (the Turbopack "Worker creator already registered" crash — the reason you switch to bundler: webpack and then hit this timeout).