Next 14.1.3 has a different behavior than above versions on fresh deployments

[zGrav]

Summary

Hey folks,

I'm trying to identify what is causing (and if I can disable this somehow) in deployments done on Next 14.2.20 on for example _next/data/[hash]/[name].json routes to 404 and trigger a full reload of the application on any subsequent navigation done, this is sadly causing a lot of load and strain on backend services with a plethora of users all refreshing at the same time as well as lots of 404 spikes in metrics, this happens with or without the usage of deploymentId and with generateBuildId.

On 14.1.3 and Next 13 (which was what I was on before), this hard/full reload of the page does not seem to happen at all.

I can reproduce this in the following steps:

• Set a build ID and do a local build
• When the local build completes, start the local server and navigate somewhere, leave the page open
• Kill the local server, change the build ID and do another local build
• When complete, start the new local build and navigate in the same page or elsewhere (using next/link items and not typing a new URL)
• On versions above 14.1.3, it will move you to the new URL but reload the entire application
• On 14.1.3, your app will move you as normal without reloads.

I'm just curious if this is intended behaviour and if there's a way to opt-out of this at all.

PS: I am running a output: standalone application and self-hosted, not running in any platform like Vercel's own nor Netlify.

Thanks!

Additional information

No response

Example

https://github.com/zGrav/dummy-debug-nextjs-refresh

[ijjk]

Hi, how did you verify this? I just did a quick test and am seeing the same behavior in 14.1.3 as 14.2.22 also we didn't land any related changes that would cause this that we are aware of.

Note, if a page uses getStaticProps it can be prefetched/cached for the browser tab's session regardless of a new deployment.

CleanShot.2025-01-16.at.13.49.20.mp4

[zGrav]

hey @ijjk , apologies for the delay, I've been pretty sick lately, I replicated this in a blank slate and I hope it's intuitive enough for you. I can also share the dummy repo I used for this.
Here's what happens on 14.2.23, note the refresh (happens with and without deploymentId) vs 14.1.3 after a new prod build trying to navigate.

14.2.23:
https://github.com/user-attachments/assets/01c80383-db4c-400b-a7a1-555045a3fad1

14.1.3:
https://github.com/user-attachments/assets/376390d7-8381-4924-bc75-a4e1ab2e72d5

[zGrav]

Okay, so I had a suspicion that it could be middleware related and it is.

After disabling it, the refresh does not happen.

This is what I am using for middleware:

import {
  NextMiddleware,
  NextRequest,
  NextFetchEvent,
  NextResponse,
} from "next/server";

const middleware: NextMiddleware = (() => {
  const middlewareFactory =
    () =>
    async (request: NextRequest, _next: NextFetchEvent, ...rest) => {
      // console.log(request);
      // console.log(_next);
      // console.log(rest);

      return NextResponse.next();
    };

  return middlewareFactory();
})();

export default middleware;

export const config = {
  matcher: [
    {
      source: "/((?!api|_next/static|_next/data|_next/webpack-hmr).*)",
      missing: [
        { type: "header", key: "next-router-prefetch" },
        { type: "header", key: "purpose", value: "prefetch" },
      ],
    },
  ],
};

I'll just push the repo for easier debugging, one sec

[zGrav]

Repo: https://github.com/zGrav/dummy-debug-nextjs-refresh

[Stanzilla]

Hey @ijjk any chance you could take a look?

[Stanzilla]

We tried again today with 14.2.20 and sadly had the same results again. Requests spiked a ton and replicas scaled to the max so we had to revert again.

[ijjk]

Hi, so this working when middleware is configured on v14.1.3 of Next.js appears to be an old bug with the build ID being stripped before validating it is the current active build ID. This is dangerous behavior as you don't want to accidentally get data from a new deployment that could not be compatible with the existing loaded client JS.

If you really want the behavior you were seeing in v14.1.3 you would have to generate a consistent build ID across your deployments but it will have the above described pitfall.

You could also achieve the above shown behavior with skew protection which is available by default on Vercel and avoids the described pitfall since it actually serves the data from the older build so they match.

[ijjk]

The buildId would have to be the exact same unless you have skew protection https://vercel.com/docs/skew-protection but again keeping the buildId the same isn't advisable as it will cause unexpected behavior across deploys if data shape changes at all and won't invalidate manifests that are build specific correctly.

[zGrav]

Noted, I'll escalate internally and see what can be done and test some other items. Thanks for the reply.

[Stanzilla]

The buildId would have to be the exact same unless you have skew protection vercel.com/docs/skew-protection but again keeping the buildId the same isn't advisable as it will cause unexpected behavior across deploys if data shape changes at all and won't invalidate manifests that are build specific correctly.

What would you say is the best practice here though in a self-hosting scenario? This all seems a bit mysterious and hidden for me?

[ijjk]

Ideally when self-hosting you still do gradual rollout and have a proxy that can route traffic depending on the deployment ID to the correct instance which allows your users to switch over to the new deployment before the old one is shutdown.

[Stanzilla]

Ideally when self-hosting you still do gradual rollout and have a proxy that can route traffic depending on the deployment ID to the correct instance which allows your users to switch over to the new deployment before the old one is shutdown.

Okay so what we ended up doing, after also reading #44596, is the following:

const computedBuildId = !localBuild
  ? `${buildConfig.GIT_COMMIT}-${buildConfig.BUILD_NUMBER}`
  : 'local';
/** @type {import('next').NextConfig} */
const nextConfig = {
  generateBuildId: async () => {
    return computedBuildId;
  },
  deploymentId: computedBuildId,
experimental: {
    // https://github.com/vercel/next.js/discussions/44596
    middlewarePrefetch: 'strict'
},
async headers() {
    const base = [
	...
],
  // Cache-control for Next data JSON responses (_next/data/<buildId>/...)
    // In production/stage builds the build id is stable per-deploy so it's
    // safe to allow long CDN caching which will greatly reduce origin load
    // caused by Link prefetch requests fetching the data JSONs.
    if (!localBuild && isStageOrProdEnv) {
      base.push({
        source: '/_next/data/:path*',
        headers: [
          {
            key: 'Cache-Control',
            value:
              'public, s-maxage=31536000, stale-while-revalidate=86400, immutable'
          }
        ]
      });
    } else {
      // During local builds / development, avoid caching so developers see
      // changes immediately.
      base.push({
        source: '/_next/data/:path*',
        headers: [
          {
            key: 'Cache-Control',
            value: 'no-cache, no-store, must-revalidate'
          }
        ]
      });
    }

    return base;
}

Does that make sense? Any suggestions?

We had to also add middlewarePrefetch: 'strict' because otherwise we had a ton JSON requests that were basically serving {} for many routes, eating our RPS. I later added extra cache headers for these files but we have not yet tested a deploy with it not on 'strict' again.

I really appreciate your help here and it seems to have unlocked upgrading to 14.2 for us. I do wish though the docs for Next were more detailed and contained more info about self-hosting use-cases. I know it is probably a business thing but it would really be appreciated.