revalidatePath is not busting client segment cache

[abuinitski]

Verify canary release

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

Provide environment information

Operating System:
 Platform: linux
 Arch: x64
 Version: #22 SMP Tue Jan 10 18:39:00 UTC 2023
Binaries:
 Node: 16.17.0
 npm: 8.15.0
 Yarn: 1.22.19
 pnpm: 7.1.0
Relevant packages:
 next: 13.4.4-canary.2
 eslint-config-next: N/A
 react: 18.2.0
 react-dom: 18.2.0
 typescript: 4.9.5

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

App directory (appDir: true)

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

https://codesandbox.io/p/sandbox/cranky-lovelace-mkjcpq

To Reproduce

1. Run provided example, start off at initial route "/", observe list of items
2. Click "Item 1", observe details page with an input
3. Click "Back", observe you're back at list page (this is important, somehow initial route does not end up in client cache)
4. Click "Item 1" again
5. Enter something different (e.g. "Item 1 updated") into the input field, click "Save", observe view is properly updated
6. Cllick "Back", observe old name is still displayed in the list page, consult logs to make sure this page was not rendered on the server, and was indeed served from client cache
7. Refresh preview page, observe new name is displayed

Describe the Bug

When Server Action triggers server mutation, and properly(?) invalidates obsolete paths, while these paths are (assumedly) removed from server cache, may still remain in client segment cache, and therefore serve incorrect data afterwards.

Expected Behavior

Since Server Action invalidated path, displaying cached version is not expected afterwards.

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

[mediabeastnz]

Also seeing this behaviour which basically makes revalidatePath() unusable

[Xexr]

Yes, this is a painful bug and I believe it has led to a large part of the noise around next link cache invalidation on this issue:

#42991 (comment)

[karlhorky]

Here's a video from the CodeSandbox demo in the description - interestingly it also sometimes succeeds 🤔 (I had it succeed multiple times before I took the video, so I thought that was actually not a problem anymore)

Kapture.2023-06-14.at.15.41.45.mp4

This is where the revalidatePath() is used in the code, since it wasn't mentioned in the issue description above:

app/[itemId]/actions.ts

"use server";

import { revalidatePath } from 'next/cache'

import { getItemsRepository } from "../_item/ItemsRepository";

export async function saveItemName(itemId: string, newName: string) {
  console.log(`SAVE: ${itemId}/${JSON.stringify(newName)}`);
  await getItemsRepository().updateItemName(itemId, newName);
  revalidatePath(`/${itemId}`);
  revalidatePath("/");
}

[karlhorky]

Just upgraded to next@13.4.6-canary.4 (latest canary) in your CodeSandbox to create this new sandbox, because of this comment and PR #50848 by @shuding

CodeSandbox demo with updated latest canary version: https://codesandbox.io/p/sandbox/charming-benji-68kx5w?file=%2Fpackage.json%3A11%2C27

And now I cannot reproduce the problem you described in the issue anymore @abuinitski (see video below)

@abuinitski can you confirm that the latest canary version next@13.4.6-canary.4 has fixed your issue? And if so, maybe close the issue too?

Kapture.2023-06-14.at.16.35.09.mp4

[shuding]

Thanks @karlhorky I believe that this is fixed with #50848.

[abuinitski]

yep, it works, thanks!

[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.