revalidate, revalidateTag and revalidatePath not working as intended

[epndavis]

Verify canary release

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

Provide environment information

Operating System:
      Platform: win32
      Arch: x64
      Version: Windows 10 Home
    Binaries:
      Node: 16.14.2
      npm: N/A
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 13.4.3-canary.0
      eslint-config-next: 13.4.1
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.0.4

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

App directory (appDir: true), Data fetching (gS(S)P, getInitialProps)

Link to the code that reproduces this issue

https://github.com/epndavis/nextjs-revalidate-issue

To Reproduce

1. Load the homepage (revalidate)

• Wait 30 seconds for GraphQl fetch to revalidate, refresh the page a couple of times to get the new data

2. Load the homepage (revalidateTag)

• Go to http://localhost:3000/api/revalidate?tag=graphql

• Back to homepage, refresh the page a couple of times to get the new data

3. Load the homepage (revalidatePath)

• Go to http://localhost:3000/api/revalidate?path=/
• Back to homepage, refresh the page a couple of times to get the new data

4. Load http://localhost:3000/dynamicGraphQl/2 (revalidatePath)

• Go to http://localhost:3000/api/revalidate?path=/dynamicGraphQl/2
• Go back to dynamic page and refresh

Describe the Bug

Steps 1 and 2 refresh all data on the page. There are two fetch requests on the homepage, one with revalidation (GRAPHQL) the other cached indefinitely (API). When revalidated through any of these methods the GRAPHQL is revalidated but the API fetch request is also revalidated.

Step 4. If revalidatePath is used on a dynamic route nothing happens unless revalidateTag is used.

Expected Behavior

We would expect that only the revalidated request is re-run, the cached fetch request should remain static. If revalidating a page it shouldn't revalidate everything unless it is requested to be revalidated as in step 3 via the path. This is as described in this youtube video and recently this tweet

We would also expect dynamic routes to be revalidated via revalidatePath .

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

[ijjk]

Hi, everything appears to be working properly in the provided reproduction with the latest canary of Next.js as can be seen in the below recording. Something to note from above is that revalidatePath should be called with the page's pathname not the URL e.g. /dynamicGraphQl/[id] and not /dynamicGraphQl/2

CleanShot.2023-05-14.at.11.18.55.mp4

[epndavis]

Thank you @ijjk for looking into this, I really appreciate it.

I can see that it works perfectly for you. However it doesn't for me as you can see in the screen recording. Each time both update, could this be a windows issue? https://github.com/vercel/next.js/assets/47059262/20cac5e1-c652-4073-b6c8-6fe86de86572

Thank you for clarifying the dynamic revalidatePath, I've seen that a lot of people seem to be unclear on this as, like me, would expect to be able to update a single path, say for example, CMS posts. Having to rebuild everyone isn't ideal, is there someway around this?

[joncoronel]

Wouldn't that mean that revalidating a dynamic path would revalidate every dynamic page generated in the cache for that dynamic route?
So if I have a hundred pages generated for a dynamic path, it would revalidate all of them? Personally, I would like to be able to revalidate a specific dynamic page instead of having to revalidate all of them.

[joncoronel]

Temporary workaround is to add a [slug] tag to the fetch functions in the dynamic path and then call revalidateTag.

[ijjk]

@joncoronel if you want to revalidate a specific pathname e.g. /blog/first you can continue to leverage On-Demand ISR although do note that revalidatePath does not revalidate all affected paths under a dynamic path immediately only when next visited so if you visit one pathname under dynamic path and then the rest are visited and the cache is already updated they will not re-fetch.

[joncoronel]

@ijjk I found that after the 13.4 update, the old method of On-Demand ISR through res.revalidate no longer works with pages in app dir. I get an error message.

Okay got it that makes more sense. So when I visit a dynamic path that was already in cache that has been revalidated through revalidatePath, would it still first show the cached version of the dynamic path and revalidate in the background similar to time-based ISR or would it wait to load the page until it is revalidated like how it would if that dynamic path has not been generated yet/not in cache?

[lseemann]

Something to note from above is that revalidatePath should be called with the page's pathname not the URL e.g. /dynamicGraphQl/[id] and not /dynamicGraphQl/2

Is this the intended behavior for revalidatePath? As @joncoronel notes, if one invokes revalidatePath, one probably intends to revalidate a single path, not all the paths that match a dynamic route.

[tutorialcode]

revalidatePath does not revalidate all affected paths under a dynamic path immediately only when next visited so if you visit one pathname under dynamic path and then the rest are visited and the cache is already updated they will not re-fetch.

@ijjk Hi, can you elaborate this more? e.g. After using validatePath('/blog/[slug]'), if i visit /blog/my-post-1, that will get regenerated, then I visit /blog/my-post-2, but that will not get regenerated because my-post-1 has been regenerated?

[mediabeastnz]

Should this be re-opened? It's still an issue as @tutorialcode pointed out

[tutorialcode]

Should this be re-opened? It's still an issue as @tutorialcode pointed out

I wasn't pointing out an issue, i was only asking for more clarification. I'm good now.

[Tommoore96]

I still have this problem.

// app/create-post/actions.ts

export async function createPost(content: string) {
  const { userId, orgId } = auth();

  await db.insert(posts).values({ content });

  revalidatePath("/view-posts");
}

// app/view-posts/page.tsx

async function getPosts() {
  "use server";

  const posts = await db
    .select()
    .from(postsTable)

  return posts;
}

export default async function Posts({
  params,
}...

I'm trying to create something on one page and revalidate another, but when I click "back" in the browser to get to /view-posts I'm only shown the old data. If I click a Link element then the /view-posts page is revalidated, although that happens regardless of whether I use revalidatePath or not.

I've tried putting some console.logs in my code and it looks like the component is rendered before the server action (getPosts) is called. 🤔

Am I using server actions wrong???

Update:

Navigating with browser' "forward" and "back" uses its own cache and there is no way to get over this without making it refetch and rerender every time it is shown which involves making it a client component and removes all advantages of having it render on the server.

[github-actions]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.