Build the web Worker before you deploy it
wrangler deploy inside the web app can ship the existing OpenNext build. A new route then 404s on the live domain even though the laptop rendered it.
Published 2026-09-10 · Search job: OpenNext Cloudflare deploy stale 404
A new public route can render on a laptop and 404 on the live domain. The usual cause here is deploying the web Worker without rebuilding it.
wrangler deploy inside the web app delegates to OpenNext. That path can upload the existing build. pnpm --filter @adp-zero/web run deploy builds first. The run word matters. Bare pnpm deploy is pnpm's own command.
We hit this while shipping publication routes. The isolated production path now uses the filter-plus-run form on purpose. If /lab or a new Guide 404s after a Worker version id printed successfully, check whether that deploy rebuilt.
Two other host traps from the same week of work
The public site is adprimezero.com. The old workers.dev hostname for the web Worker returns Cloudflare 1042 because workers.dev was disabled after the custom-domain deploy. Use the custom domain for user-facing checks.
A destination-fixture Worker on workers.dev returned 200 locally and 404 when the production API crawler fetched it. The fixture now lives on approval-fixtures.adprimezero.com. Worker-to-Worker fetches to sibling workers.dev hosts are also a known 1042 class of bug. The repo has a static guard for that pattern.
Why this is a Note
It looks like an application bug. It is a release-path bug. The page existed in git. The Worker was serving yesterday's bundle. That is the same "one confident check" shape as four wrong capability claims: the deploy command exited 0, so the route "must" be live.