#edge-cache

Jacob Paris Can you share what version of Next.js you're on? Next 16 uses Turbopack instead of Webpack so you shouldn't be getting errors like this on up to date versions

Ngoiyaeric I fixed it with sse-error-extension-conflict

system There's another community post with 404 debugging tips that might be helpful. Please give these solutions a try and let us know how it goes. https://community.vercel.com/t/debugging-404-errors/437 A human should be around soon to offer more advice. But you can also get helpful information quickly by asking v0.

Thiego Thanks. I reviewed the 404 debugging guide. The common 404 causes listed there do not appear to match this case: - the active Preview deployment exists and is READY - the immutable deployment URL is correct - /login loads successfully - initial _next assets load successfully - build output is healthy - there is no vercel.json - repository configuration does not rewrite or cache /login POST requests - Deployment Protection/OIDC access is working The 404 only occurs after submitting the Next.js Server Action. The POST /login response is returned with: x-vercel-cache: HIT and contains an x-nextjs-deployment-id from an older deployment. The stale Server Action/RSC payload then references build-specific assets from that older deployment, and those asset requests return 404 on the current immutable deployment. So the 404 appears to be a downstream symptom of the stale cached Server Action response, rather than a missing route or deployment-output issue. Could a human from the Edge/Next.js platform team please review the x-vercel-cache: HIT / stale x-nextjs-deployment-id behavior?

Jacob Paris Unfortunately we can't unpause your account until the usage rolls over back below its limits, otherwise it would repause immediately. You'll need to either upgrade or wait it out

Deji Ice how long do i have to wait?

system There's another community post with 404 debugging tips that might be helpful. Please give these solutions a try and let us know how it goes. https://community.vercel.com/t/debugging-404-errors/437 A human should be around soon to offer more advice. But you can also get helpful information quickly by asking v0.

Ryu Hi Aman, I’d check `use cache` itself first. Even if you did not set `export const revalidate = X`, `use cache` has its own cache lifetime behavior. The default profile includes a server-side revalidation window, so it may not behave like “only regenerate when I call `revalidateTag`.” That default is described here: https://nextjs.org/docs/app/api-reference/directives/use-cache For your case, I’d try to separate three possible triggers: 1. **`use cache` default revalidation** Add an explicit `cacheLife()` profile to the cached function/component so you know exactly when it can revalidate, instead of relying on the default. 2. **Bot or prefetch traffic** A “couple real visitors” can still create many page reads if crawlers, link previews, uptime tools, or `next/link` prefetching touch many slug pages. If you have an index page linking to hundreds of dynamic routes, try temporarily setting `prefetch={false}` on those links and see if ISR reads drop. 3. **Hidden requests that do not show up where you expect** Cached page hits may not look like normal server logs. I’d use Vercel Observability / Runtime Logs and filter by path, user-agent, and rendering/cache mechanism around the ISR spike time. If needed, add very temporary middleware for `/[slug]` that logs only non-sensitive fields like path, user-agent, referer, and timestamp. If the timestamps of ISR reads line up with bot/prefetch requests, then the cache is being touched by real HTTP traffic, just not human visitors. If ISR writes continue for slugs with no matching request at all, then I’d share a small sample of affected paths and timestamps, because that would be much stronger evidence of something internal or unexpected.

Ryu Hi Devansh, If those Sentry events cluster around deploy times, I’d treat this as version skew first. With `dynamic(() => import(...), { ssr: false })`, the browser may not request that CSS/JS chunk until later. If the user loaded HTML/JS from an older deployment, then a new production deployment goes live, that old client can later try to fetch a chunk URL that no longer exists on the deployment it is being routed to. That usually shows up as: ``` Loading CSS chunk failed /_next/static/css/<hash>.css ``` A good way to confirm is to check the failed asset request in Sentry or browser devtools: ``` status: 404 or failed network request url: /_next/static/css/... time: close to a new deployment ``` I’d also compare one failed chunk URL directly: ``` curl -I https://your-domain.com/_next/static/css/FAILED_HASH.css ``` If it returns `404`, and the event happened after a deployment, that strongly points to stale client/runtime vs new deployment assets rather than a normal React error. A few mitigations I’d check: * enable/verify Vercel Skew Protection if your plan/project supports it * make sure HTML/RSC responses are not being cached by an extra CDN/proxy in front of Vercel * do not override caching for `/_next/static/*` * keep deployment retention / skew max age long enough for typical user sessions * add a one-time reload fallback for chunk-load failures so users recover instead of staying on a broken page Vercel’s Skew Protection docs describe the exact problem: keeping framework-managed JS/CSS/data requests pinned to the deployment that served the original page: https://vercel.com/docs/skew-protection I would not remove `dynamic()` just because of this. Dynamic imports can make the issue more visible because chunks are requested later, but the underlying thing to prove is whether the failed CSS URL is from an older deployment and returning 404 after rollout.