Router Cache not working after first invalidation

[seho0808]

Link to the code that reproduces this issue

https://github.com/seho0808/next_js_13_caching_test

To Reproduce

I found an error with Router Cache. This app works fine initially: Server Component's RSC Payload stays cached on browser for the first five minutes (dynamic page). However, after 5 minutes, when first invalidation happens, it just never gets cached again and keeps fetching on every single navigation. If I refresh the page, the Router Cache becomes fine again until the next invalidation.

To run the app, please follow the commands below.

# start the node server first (which provides an example api endpoint of https://localhost:8001
node server.js

# start the next.js web server
npm install
npm run build
npm run start

After the app is ready, please run the steps below.

1. First if you go to http://localhost:3000, you will see the two values (from client: some value and from server: some value)

2. If you navigate between the hello page and the home page, you can see the Router Cache works perfectly, only caching the server component render.

3. Now switch tab and do other things for 5 minutes (invalidation time for dynamic route)

4. Come back and again navigate between hello page and home page.

5. Now both values change every time you navigate... Is this an intended behavior???

6. If I refresh, it works again...

Current vs. Expected behavior

Current Behavior: My app example's Router Cache caches server component's value until the first invalidation. After the first invalidation, server component rendered on browser changes its value every single time I navigate between pages with Link component.

Expected Behavior: Dynamic Page RSC Payload is supposed to be re-cached every 5 minutes, so the data within Server Component is expected to only change every 5 minutes unless I refresh(which manually invalidates Router Cache).

Verify canary release

• [X] 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 Pro
Binaries:
  Node: 18.16.0
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.0.3
  eslint-config-next: 14.0.3
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.3.2
Next.js Config:
  output: N/A

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

Not sure, Data fetching (gS(S)P, getInitialProps)

Additional context

I tried testing on 14.0.3 and 14.0.4-canary.6. Both had the same issue.

_NEXT-2436

[nobu-sh]

Similar issue here. Its more like after ~45 seconds for me though and it starts caching again after ~1 minute but then repeats this behavior.

[cognivator]

+1 And mine seems to invalidate after much less than 5 mins, too... maybe the 30 secs. you expect from a dynamic render or dynamic route. Also FWIW, this is both a dev-time (run dev) and prod-time (run build, run start) occurrence for me on localhost.

In my case, I'm using parallel routes, not dynamic route, but perhaps it's hitting the same / similar bug under the hood?

I'm re-testing without the parallel routes and will report back.

[loremipson]

Not much to add, just confirming this issue on my end. I've been going crazy trying to figure out what I've been doing wrong.

Mine is around 45 sec as well, despite export const revalidate = 3600 in the page using reacts cache() on a third-party dataset with Prisma.

[yurinog]

Same here, also around 45 sec. Feels pretty obscure how to handle these caching cases, hard to tell if I'm doing something wrong on my side or it's just a bug.

Edit: a session cookie expired so I had to log in again and aparently the function that is being cached is working like expected. Not sure why. Maybe it has something to do with the fact that the cookie was set still in dev's mode session, while the second time it was set during production/build session.

Edit 2: worked for a couple of minutes, now it's invalidating again. Well... Probably has something to do with cookies in my case. https://nextjs.org/docs/app/building-your-application/data-fetching/fetching-caching-and-revalidating

I will try more tests later

[ayhanap]

Can be reproduced with app router playground. Still the same problem with 14.1.0.

Check the video for a reproducer. https://github.com/vercel/next.js/assets/5447639/f85b7fd7-99d3-4b5f-98fb-f02fac9c389b

[vasyaqwe]

Can be reproduced with app router playground. Still the same problem with 14.1.0.

Check the video for a reproducer. https://github.com/vercel/next.js/assets/5447639/f85b7fd7-99d3-4b5f-98fb-f02fac9c389b

Happening to me too. Exactly like on the vid

[nobu-sh]

Can be reproduced with app router playground. Still the same problem with 14.1.0.

Check the video for a reproducer. vercel/next.js/assets/5447639/f85b7fd7-99d3-4b5f-98fb-f02fac9c389b

Yep, exactly what is occurring with me; at first I thought it might be something to do with the supabase ssr setup, but this validates not 👍

[Francesco-Rizzi]

+1

Can confirm, issue still present with next: 14.1.0, both DEV and PROD.

I read a lot of documentation and I thought I was doing something wrong, but apparently it seems a bug.

The first navigations are fine, the route segments are cache as expected by the router-cache. But when the first invalidation hits, then it breaks. On a subsequent navigation, it purges the cache and makes a new HTTP call to re-render the changed route segments (as expected), but then fails to save the fresh response in the cache, leading to a new call/refresh on every navigation.

@timneutkens ?

[github-actions[bot]]

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