null is not an object (evaluating 't.parallelRoutes.get')

[JClackett]

Link to the code that reproduces this issue

https://github.com/JClackett/next-reproduction-app

To Reproduce

So, I literally have no idea how to reproduce this consistently yet, but will keep trying.

I'm getting this error semi-often in production only and only sometimes for certain users, most of the time it's working.

Looking at the stack trace (which is limited), it's due to some call to a <cache>.parallelRoutes.get. Searching the next code base with https://github.com/search?q=repo%3Avercel%2Fnext.js%20parallelRoutes.get&type=code
shows all the times this method is called.

It seems that one of the cache objects is null for me? How would I go about creating a repro for that. Or does anyone have any idea why this cache object would be null in the first place. The page this is erroring on is nothing special, it's just a async server component that fetches data and renders few components, one being a client component, so I dont see (yet) how this is something strange with my setup. Only thing of note is that im using react suspense to handle the fallback because the loading.tsx pages dont work as id like (they dont trigger on search param changes).

Current vs. Expected behavior

Doesn't crash

Provide environment information

Like I said, only in production and on vercel.
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.1.0: Mon Oct  9 21:27:24 PDT 2023; root:xnu-10002.41.9~6/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 8
Binaries:
  Node: 18.18.2
  npm: 9.8.1
  Yarn: 1.22.19
  pnpm: 8.15.7
Relevant Packages:
  next: 14.2.5 // Latest available version is detected (14.2.5).
  eslint-config-next: N/A
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.5.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Navigation, Runtime

Which stage(s) are affected? (Select all that apply)

Vercel (Deployed)

Additional context

Only in production on vercel

[JClackett]

At the same time as this error I get the:
"async/await is not yet supported in Client Components, only Server Components." error from React (https://react.dev/errors/482).

But im not using async client components, im using async in a server component as shown in the repro. But is there some caveats to that that im not aware of? I am calling a server action from the client component that renders.

But the next.js error is always coupled with this react error, so maybe theres a connection?

[JClackett]

Looking into the breadcrumbs of what the user did, its not on navigating to the page, its when they submit the server action, but they did it 3 times successfully and then on the 4th time it caused these errors.

[JClackett]

Still getting this when certain users call a server action

[shiam-technext]

I'm also encountering this issue in production. It seems to be coming from one of the static chunk files. Below is a code snippet where the error is being triggered:

function(e, t, n) {
      "use strict";
      Object.defineProperty(t, "__esModule", {
          value: !0
      }),
      Object.defineProperty(t, "fillCacheWithNewSubTreeData", {
          enumerable: !0,
          get: function() {
              return function e(t, n, s, u) {
                  let l = s.length <= 5
                    , [c,f] = s
                    , d = (0,
                  a.createRouterCacheKey)(f)
                    , p = n.parallelRoutes.get(c);
                  if (!p)
                      return;
                  let h = t.parallelRoutes.get(c);
                  h && h !== p || (h = new Map(p),
                  t.parallelRoutes.set(c, h));
                  let m = p.get(d)
                    , g = h.get(d);
                  if (l) {
                      if (!g || !g.data || g === m) {
                          let e = s[3]
                            , t = e[2];
                          g = {
                              status: r.CacheStates.READY,
                              data: null,
                              subTreeData: t,
                              parallelRoutes: m ? new Map(m.parallelRoutes) : new Map
                          },
                          m && (0,
                          o.invalidateCacheByRouterState)(g, m, s[2]),
                          (0,
                          i.fillLazyItemsTillLeafWithHead)(g, m, s[2], e, s[4], u),
                          h.set(d, g)
                      }
                      return
                  }
                  g && m && (g === m && (g = {
                      status: g.status,
                      data: g.data,
                      subTreeData: g.subTreeData,
                      parallelRoutes: new Map(g.parallelRoutes)
                  },
                  h.set(d, g)),
                  e(g, m, s.slice(2), u))
              }
          }
      });

This error surfaces with the message: "null is not an object (evaluating 't.parallelRoutes.get')".

Has anyone found a workaround or fix for this yet? Any insights would be appreciated.

Thanks!
Md. Shafiul Alam

Edit by maintainer bot: Comment was automatically minimized because it was considered unhelpful. (If you think this was by mistake, let us know). Please only comment if it adds context to the issue. If you want to express that you have the same problem, use the upvote 👍 on the issue description or subscribe to the issue for updates. Thanks!

[MattisAbrahamsson]

Also seeing this issue a lot in Sentry. We are not using parallel routes at all.
Also seeing the "async/await is not yet supported in Client Components, only Server Components." error occur right before, we are not using any async server components yet, so no issue with our code that I could find

[github-actions]

We cannot recreate the issue with the provided information. Please add a reproduction in order for us to be able to investigate.

Why was this issue marked with the please add a complete reproduction label?

To be able to investigate, we need access to a reproduction to identify what triggered the issue. We prefer a link to a public GitHub repository (template for App Router, template for Pages Router), but you can also use these templates: CodeSandbox: App Router or CodeSandbox: Pages Router.

To make sure the issue is resolved as quickly as possible, please make sure that the reproduction is as minimal as possible. This means that you should remove unnecessary code, files, and dependencies that do not contribute to the issue. Ensure your reproduction does not depend on secrets, 3rd party registries, private dependencies, or any other data that cannot be made public. Avoid a reproduction including a whole monorepo (unless relevant to the issue). The easier it is to reproduce the issue, the quicker we can help.

Please test your reproduction against the latest version of Next.js (next@canary) to make sure your issue has not already been fixed.

If you cannot create a clean reproduction, another way you can help the maintainers' job is to pinpoint the canary version of next that introduced the issue. Check out our releases, and try to find the first canary release that introduced the issue. This will help us narrow down the scope of the issue, and possibly point to the PR/code change that introduced it. You can install a specific version of next by running npm install next@<version>.

I added a link, why was it still marked?

Ensure the link is pointing to a codebase that is accessible (e.g. not a private repository). "example.com", "n/a", "will add later", etc. are not acceptable links -- we need to see a public codebase. See the above section for accepted links.

What happens if I don't provide a sufficient minimal reproduction?

Issues with the please add a complete reproduction label that receives no meaningful activity (e.g. new comments with a reproduction link) are automatically closed and locked after 30 days.

If your issue has not been resolved in that time and it has been closed/locked, please open a new issue with the required reproduction.

I did not open this issue, but it is relevant to me, what can I do to help?

Anyone experiencing the same issue is welcome to provide a minimal reproduction following the above steps. Furthermore, you can upvote the issue using the 👍 reaction on the topmost comment (please do not comment "I have the same issue" without reproduction steps). Then, we can sort issues by votes to prioritize.

I think my reproduction is good enough, why aren't you looking into it quicker?

We look into every Next.js issue and constantly monitor open issues for new comments.

However, sometimes we might miss one or two due to the popularity/high traffic of the repository. We apologize, and kindly ask you to refrain from tagging core maintainers, as that will usually not result in increased priority.

Upvoting issues to show your interest will help us prioritize and address them as quickly as possible. That said, every issue is important to us, and if an issue gets closed by accident, we encourage you to open a new one linking to the old issue and we will look into it.

Useful Resources

• How to Contribute to Open Source (Next.js)
• How to create a Minimal, Complete, and Verifiable example
• Reporting a Next.js bug
• Next.js Triaging issues

[richardhenry]

I'm also seeing this issue somewhat frequently for our users in production, when a server action is called in response to a user action:

This might be a red herring, but it seems to only be happening for users on Mobile Safari:

Perhaps this only happens on higher latency connections? I'm not sure.

[JClackett]

Im wondering if it's something to do with deployment skew, I got a lot of errors just after I deployed a new version - though I cant replicate :(

[richardhenry]

Im wondering if it's something to do with deployment skew, I got a lot of errors just after I deployed a new version - though I cant replicate :(

I asked a few users that experienced this error about how they use the web app, and they all said that they tend to keep a tab with the app open for a very long time (i.e. many hours/days) and go back to it. So I think that's a pretty good theory.