On-demand ISR do not work correctly

Verify canary release

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

Provide environment information

 npx next info
/bin/sh: pnpm: command not found

    Operating System:
      Platform: darwin
      Arch: x64
      Version: Darwin Kernel Version 21.3.0: Wed Jan  5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_ARM64_T6000
    Binaries:
      Node: 16.14.0
      npm: 8.3.1
      Yarn: 1.22.17
      pnpm: N/A
    Relevant packages:
      next: 12.1.0
      react: 17.0.2
      react-dom: 17.0.2

warn  - Latest canary version not detected, detected: "12.1.0", newest: "12.1.1-canary.16".
        Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue.
        Read more - https://nextjs.org/docs/messages/opening-an-issue

What browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

Vercel

Describe the Bug

We have a NextJS front end and Sanity.io for the back end. I implement the on-demand ISR API on the /api/revalidate path, which is called whenever Sanity content changed. Before this, we use the time-based ISR, but I have removed that part of the code.

When deploy on Vercel, I tested by modifying the content in Sanity and it works correctly: the API is called and the page is updated, but if I make the next changes within a few minutes or so, the page won’t update, even though the API is called properly in the log without catching any error. This happens most of the time, but not all the time. Sometimes, I try to trigger the API call from Insomnia, the page update again with the latest info. But most of the time, I have to wait a few mins, change the content in Sanity and Publish again for it to work.

If I wait for a few minutes after the first revalidation and call the API again, most of the time, the page is updated correctly. But still, not all the time. I wonder if this has anything to do with the fact that we used time-based revalidation before. Maybe some caching laying around, not sure.

On an addition note, when I test the revalidate API call from Insomnia, for both local prod build or Vercel deployed build, sometimes, it takes a whole minute to resolve the query. So one of the possibility is that Vercel has a timeout config for a function call.

Also another quick note that might help others: we use Next middleware auth to block people from visiting our development page, when I call the revalidation API, it is blocked by the popup therefore only always throw errors. The error message was only Failed to revalidate ${urlPath} and I was only able to fix it by deep-dive into the function. Maybe throwing the error with the actual result of the fetch instead would be more helpful? 😃

Thank you!

Expected Behavior

Whenever the /api/revalidate API call, force update the page content

To Reproduce

[mavic111]

I think I found the problem. When i use sanityClient to fetch the props with useCdn: true. The data is coming from CDN that was cached and not updated. After I change useCdn to false, the props that fetched using GetStaticProps now always up to date.

[turboninh]

@rodrigo-arias I see this in production 😦