Understanding revalidate and blocking.
Unanswered
Brown bear posted this in #help-forum
Brown bearOP
I just want to understand if this process is the correct behavior.
The expected sequence is this:
Revalidate landing page.
Visit landing page, presented with stale page.
Refresh and server updated page.
However, in actual, this is what happens:
Revalidate landing page.
Visit landing page, serverless function blocks user for > 3s, sometimes even more.
New page is served.
Is this suppose to happen? I thought a stale page is supposed to be served. If this is not the expected behavior, any clues on maybe what is preventing it from serving the stale page first, before going into revalidation?
The landing page is built as a static page, with some fetch calls.
The expected sequence is this:
Revalidate landing page.
Visit landing page, presented with stale page.
Refresh and server updated page.
However, in actual, this is what happens:
Revalidate landing page.
Visit landing page, serverless function blocks user for > 3s, sometimes even more.
New page is served.
Is this suppose to happen? I thought a stale page is supposed to be served. If this is not the expected behavior, any clues on maybe what is preventing it from serving the stale page first, before going into revalidation?
The landing page is built as a static page, with some fetch calls.
19 Replies
Thats not possible, basically when you use a route handler to revalidate a page, on the next request it will be revalidated. If the next request is you opening the page after the call, its gonna delete the cache and get new data
what you can do is add suspense to all the components, so it wont be blocking.
Brown bearOP
Then what does serving stale data on revalidate actually means?
Thanks for replying!
basically if you run the revalidate from a route handler while you are still on the page and dont do a router.refresh() you will see the stale data.
As mentioned, on the next request it will load the new data
Or if you add a router.refresh()
Or if you add a router.refresh()
Brown bearOP
ok so this behavior is correct then. So the best way it to revalidate, and use a fetch call to visit the page so it revalidates in the background?
I dont think if you just do a get request to the page, the data is fetched and cached, you will need someone else to confirm.. sorry
but what i usualy do, is that if its a very resource intensive fetch, just add suspense to everything
Brown bearOP
ok thanks I have to balance it then.
One last question, do you know why sometimes this is happening? Sometimes it just time out, but from what I see the real time is no even 10s before this error is returned.
It is very inconsistent, and causes 504. Usually a successful revalidate at most takes about 5-6s
It is very inconsistent, and causes 504. Usually a successful revalidate at most takes about 5-6s
@Brown bear I just want to understand if this process is the correct behavior.
The expected sequence is this:
Revalidate landing page.
Visit landing page, presented with stale page.
Refresh and server updated page.
However, in actual, this is what happens:
Revalidate landing page.
Visit landing page, serverless function blocks user for > 3s, sometimes even more.
New page is served.
Is this suppose to happen? I thought a stale page is supposed to be served. If this is not the expected behavior, any clues on maybe what is preventing it from serving the stale page first, before going into revalidation?
The landing page is built as a static page, with some fetch calls.
do you mean you are using
revalidatePath or revalidateTag inside the page? or how do you revalidate the landing page?Brown bearOP
I am using wordpress for CMS. So whenever I publish or update the landing page, I will call the revalidateTag from my FE website api via wordpress.
@Brown bear I am using wordpress for CMS. So whenever I publish or update the landing page, I will call the revalidateTag from my FE website api via wordpress.
how large is your data cache? I would suggest test the site on locally
if everything work fine on locally, then you might want to contact vercel support
@Ray how large is your data cache? I would suggest test the site on locally
i dont see anything wrong with the first issue tbh
the timed out one is weird, i agree
@Ray how large is your data cache? I would suggest test the site on locally
Brown bearOP
How do I check the data cache size? Can't find on the usage tab.
Local works fine, doesn't crash at all.
Local works fine, doesn't crash at all.
Brown bearOP
Not sure how to debug this 10s timeout to be honest. I put logs on the page like on the 1st line, it does not even print when it does this timeout.
So it appears that the timeout happens before hitting the page.
So it appears that the timeout happens before hitting the page.