unstable_revalidate supported ?

[manojHDwork]

Describe the bug
Is unstable_revalidate supported?

[dphang]

I believe this is part of Incremental Static Regeneration, I think it is discussed here: #355 (comment) but not yet implemented as far as I know.

[ezalorsara]

I hope unstable_revalidate will be supported soon

[hideokamoto]

That means, currently, the Incremental Static Regeneration does not supported?

[arelaxend]

vercel/next.js#11552
#559

In this case, this thread is a duplicate of other thread.

https://nextjs.org/blog/next-9-4#incremental-static-regeneration-beta

That one will be tricky to implement. We could discuss it separately after this RFC is completed.

@danielcondemarin @dphang - do you have any update regarding implentation of revalidate for getStaticProps ?

Implementing revalidate is a tricky one I might have underestimated. In order to implement the stale-while-revalidate spec properly you have to generate a fresh copy of the page in the background whilst serving the stale copy in a non-blocking fashion. Doing that in Lambda is not possible due the way the lambda execution environment works. In other words, Lambda doesn't let you return a response to the client and keep on running a task on the background. The closest thing to running something in the background is to set callbackWaitsForEmptyEventLoop to false but that freezes outstanding events so not even that would work.
I need to take a closer look at Next.js implementation as I'm not sure if they conform strictly to the spec. Any ideas / suggestions please let me know 🙂

I wonder what I'm missing here - A separate lambda invocation makes sense, but why would SQS, or anything else on top be necessary? Couldn't the first Lambda just invoke the second lambda with InvocationType Event and not await its result?

You're right @janus-reith. That removes the need for SQS even though I think AWS still uses a queue behind the scenes for async invocations, but if is abstracting it away from us that's best!

My only remaining concern would be latency between regions, say that a user is in us-east-1 and hits one of the edge functions in that region, when invoking the other lambda for background page regeneration what latency are we expected to see? I realise that it won't need to wait for the regeneration lambda to process but the request itself to put the event in the queue what region is that happening and how do we know is not going to a queue somewhere in eu-*.
My initial guess would be the queue AWS uses behind the scenes would be colocated in the same region as the async lambda but I'm not sure of that.

Originally posted by @danielcondemarin in #355 (comment)

To fix it, we need to make the fallback page never cached, so the lambda can return the newly generated page (and cache it) the next time the same route is hit. But we also need to version the pages properly as I realized we are not clearing them properly (we only have one set of pages under static-pages, so subsequent deploys may pick up an old version).

Originally posted by @dphang in #798 (comment)

Also :

• https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/UpdatingExistingObjects.html#ReplacingObjects
• https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html
• https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_RequestSyntax

Can one adds this feature to the schedule ? This RFC is older than the v10, back to 9.4 👍

[dphang]

This can be closed now as revalidate is implemented already (using SQS queue). Please report any issues in: #1098