next.js: revalidatePath() not working as expected for Parallel Routes, or for Parallel + Intercepting Routes (modal)

Verify canary release

  • I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: darwin
      Arch: x64
      Version: Darwin Kernel Version 21.6.0: Thu Jun  8 23:57:12 PDT 2023; root:xnu-8020.240.18.701.6~1/RELEASE_X86_64
    Binaries:
      Node: 20.5.1
      npm: 9.8.0
      Yarn: 1.22.19
      pnpm: 8.6.12
    Relevant Packages:
      next: 13.4.17
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
      typescript: N/A
    Next.js Config:
      output: N/A

Which area(s) of Next.js are affected? (leave empty if unsure)

App Router

Link to the code that reproduces this issue or a replay of the bug

https://github.com/magoz/revalidatepath-parallel-routes-bug

To Reproduce

Click on Parallel+Intercepting Modal.

Describe the Bug

When clicking on the Trigger Server Action button, the server action is triggered just by fetching a new random number and passing it to a client component.

It works perfectly for the Home Page, and a Leaf Page.

But for a Page that uses Parallel + Intercepting Routes (modal), revalidatePath('/parallel-intercepting') seems to fetch the new data, and the component appears to receive the new props (see client console), but it doesn’t re-render.

For a page that uses Parallel Routes (modal without Intercepting), works as expected on hard navigation, but on soft navigation we get the same issue than the Parallel + Intercepting Routes case.

Expected Behavior

revalidatePath() to work as expected for Parallel Routes, and for Parallel + Intercepting Routes.

Which browser are you using? (if relevant)

Chrome 115.0.5790.170

How are you deploying your application? (if relevant)

pnpm dev

NEXT-1706

About this issue

  • Original URL
  • State: closed
  • Created 10 months ago
  • Reactions: 24
  • Comments: 32 (3 by maintainers)

Commits related to this issue

Most upvoted comments

we’re definitely investigating 😃

Here’s as minimal reproduction as I could make: 🐛 https://github.com/tsnieman/nextjs-parallel-route-pain/ it’s currently using next@14.0.5-canary.2

Please let me know if there’s more that i can provide. this bug is a real pain that my team doesn’t have a workaround for. EDIT — the best workaround i’ve found is to use something like router.push(`?ts=${Date.now()}`) — and be sure that you dont use router.refresh(), revalidatePath, etc. The key is to coerce the page into updating rather than explicitly asking the page to update.

and here’s a video of the bug in action:

https://github.com/vercel/next.js/assets/595711/a98bb2ca-ab4e-48f9-bc66-1d6641cc5ce9

seems like a main issue now, cuz block using forms in modals

This issue absolutely persists and can be easily reproduced. Can we have at least acknowledgement from the team that they are aware and working on it? Parallel routes are completely useless in current state.

I too was plagued by this bug. I temporarily added the following settings to work around it, but the cache is no longer meaningful.

export const dynamic = "force-dynamic";

Given that parallel routes are the recommended way to render modals (https://nextjs.org/docs/app/building-your-application/routing/parallel-routes#modals), this bug breaks the recommended way to submit forms in modals.

Totally. I don’t understand how the community isn’t freaking out about this tbh.

I also find that this same problem exists for revalidateTag.

Hey @ztanner thanks for putting the latest commit in, really appreciated 🙏 I’ve pulled the latest canary that contains your changes but still doesn’t seem to working. I’ve tested with router.refresh client side and a revalidateTag/Path on a server action and both times the 404 page is called Any thoughts on what might be happening?

There is a commit that went in recently by @ztanner (thank you!) which mentions the nextUrl in the header can cause issues with server actions https://github.com/vercel/next.js/pull/59175

Perhaps a solution in the same area could be found for revalidateTag and and revalidatePath? @ztanner do you have any thoughts?

The most recent update fixed the issue on the default page for the form, however, the bug still persists when submitting the form from a modal using parallel routing.

revalidation is breaking in all way!

we’re definitely investigating 😃

Thank you @feedthejim 🙏 I’m happy to help in any way, just shout and I’m there