Next.js Discord

Discord Forum

ISR shared cache

Unanswered
Paul. posted this in #help-forum
Open in Discord
Paul.OP
According to the docs you can provide a custom location of where the cache would be saved: https://nextjs.org/docs/app/building-your-application/deploying#caching-and-isr

However - I don't seem to be able to find it anywhere in code. I also followed the template for cache-in-redis, but that doesn't seem to do much.

I'm trying to get an endpoint up that will revalidate the entire layout of my app with revalidatePath('/', 'layout');. This doesn't refresh the layout - and will just keep serving the old state.

What am I doing wrong?

89 Replies

Eric Burel
I didn't know this was possible
So first did you try to debug the thing? is your custom handler correctly called?
you are talking about Redis but did you try the demo code they show with a basic in memory Map?
Paul.OP
Yeah, I added logging to the set and get methods of the in-memory map
But it's never getting called for any page routes
One thing I did find out is that my build export says the page in question [[...slug]] is build with SSG instead of ISG.

Even though I have export const dynamicParams = true; at the top of that page. Shouldn't that disable SSG?
Paul.OP
Unless I'm mis-understanding how the caching in Next works.

I'm using React's use function to fetch an endpoint. When logging the result of this use function this is not changed, even thought the result of the endpoint has changed.

But what I'm confused at is whether this 'caching' comes from Next or React.
so I can't tell much
in my understanding
"use" is a tool for getting data asynchronously from the client
the ISR cache is a shared server cache = the cache for static pages
I think it's ok if your slug page shows SSG
because ISR is SSG + revalidation so perhaps Next doesn't show the difference there, I don't remember
@Eric Burel "use" is a tool for getting data asynchronously from the client
Paul.OP
It shouldn't? In my use case all the components are serverside components.
Eric Burel
if your custom cache handler is not called, that might be a bug
are you using the most recent versions
Paul.OP
Yeah
RSCs can do direct async/await
use exists because it will never happen client-side
@Eric Burel why do you need "use" then?
Paul.OP
Since it's more clean than throwing Suspenses everywhere
Eric Burel
so you need a synchronous abstraction like "use"
hmm ok, I can't tell the best practices for sure yet so maybe it's right, but I lack documentation to answer
anyway that should not be related with the ISR cache
it's jsut the way you get the data from React but the cache is a server thingy
Paul.OP
Then maybe it's endpoint caching, like the fetch-api cache
Eric Burel
if it's not called then that might be a plain bug, or maybe it only works in certain version of Next
Paul.OP
Although I'm unsure where those results should be stored, if not in-memory?
@Paul. Then maybe it's endpoint caching, like the fetch-api cache
Eric Burel
if you have a POST endpoint that does a revalidate, normally it should revalidate, you should see a log from your custom cache
if the UI doesn't get the update, that's another problem
Paul.OP
I'm debugging on my server, and the server doesn't get the newest API response, even after doing the POST revalidate
So maybe I'm doing something wrong with the revalidatePath?
Eric Burel
Maybe try with a "normal" cache
then with your custom cache
Paul.OP
Even with the normal cache it doesn't revalidate
That's when I tried the custom cache
Eric Burel
yeah ok so you need to start there
Paul.OP
import { revalidatePath } from 'next/cache';
import { NextRequest, NextResponse } from 'next/server';

// eslint-disable-next-line @typescript-eslint/require-await
export async function POST(request: NextRequest): Promise<NextResponse> {
  const secret = request.nextUrl.searchParams.get('secret');

  if (secret !== process.env.REVALIDATE_SECRET) {
    return NextResponse.json(
      { error: 'Invalid secret' },
      { status: 401, statusText: 'Unauthorized' }
    );
  }
  
  revalidatePath('/[[...slug]]', 'page');
  return NextResponse.json({ revalidated: true, now: Date.now() });
}
Eric Burel
I've seen a similar issue in this area
let me share
but it was more related to middlewares
do you pass your secret check?
you'll want to add logs
Paul.OP
Yeah I do, the route returns the revalidated: true part
Eric Burel
some versions of Next just have plain buggy revalidation so you also want to try recent versions
Paul.OP
You mean downgrade?
Eric Burel
if you are on the latest version then no keep it as is but it could be just a bug
anyway that's your starting point, before talking about ISR
the issue is that your revalidatePath doesn't seem to revalidate
I've never tried with an optional param + nested segment
maybe give a shot at a minimal repro with the same page structure
Paul.OP
I don't have a nested segment?
Eric Burel
I forgot the name but the [...slug]
I don't remember how they call these spread dynamic params
Paul.OP
oh right, catch-all segments
Eric Burel
ah yeah, catch-all + optional
maybe try a non-optional
and a non-catch-all
[slug]
[[slug]]
[...slug]
and [[...slug]]
to see when it's problematic
that's tedious sorry but only way to tell what happens
Perhaps it's just unsupported/buggy in some cases
Paul.OP
Just for the record, the revalidatePath should look like this, right? revalidatepath('/[[...slug]]', 'page');
@Eric Burel [...slug]
Paul.OP
I can't even seem to get it to work for just [slug]?
export const dynamicParams = true;
export const revalidate = false;

export default function Page() {
  ...
}

export function generateStaticParams(): {slug: string}[] {
  return [{slug: 'features'}];
}


  revalidatePath('/[slug]', 'page');
  revalidatePath('/', 'layout');

I tried both forms of revalidation. Neither seem to work 👀
Is there a way to force the entire cache to just flush? Like - also flush all the fetch cache
Hmm - here's some weird behaviour;

If I go to the slug of a page that is defined in generateStaticParams it's not using any cached response. Where as if I go to a slug which isn't defined in generateStaticParams I am hitting an infinite cache, for what it seems like.
Eric Burel
first don't forget to remove .next from time to time
export const revalidate = false;
maybe remove that?
I am hitting an infinite cache,
sorry not sure what you mean
you have dynamic params so unseen params should trigger a new render, that will be cached
at least it was worth a try your issue more revalidation plain not working here
I'm starting to doubt I'm doing this revalidate thing wrong xD
@Eric Burel you have dynamic params so unseen params should trigger a new render, that will be cached
Paul.OP
Nah that's expected I know. But then, when calling the revalidate POST endpoint ONLY endpoints that are unseen during build revalidate. The rest remain cached from during build.
Like - I can't seem to revalidate the dynamic pages that were build during build-time.
if that still doesn't work I think you'd want to take a look at open issue and file a bug ticket if it's not a known issue
@Eric Burel if that still doesn't work I think you'd want to take a look at open issue and file a bug ticket if it's not a known issue
Paul.OP
Anyways, I'll see if I can make a bug about it. Thanks for your help so far! 😄
@Paul. Anyways, I'll see if I can make a bug about it. Thanks for your help so far! 😄
Eric Burel
your welcome feel free to tag me on the bug ticket "@eric-burel"