`unstable_cache` with certain value of revalidation interval persisted incorrectly in production build about next.js HOT 4 OPEN

One week later, it seems both reproducers are successfully revalidated:

• CodeSandbox reproducer (Canary) timestamp: 1721659019626
• Vercel production deployment reproducer (Next 15 RC) timestamp: 1721659017469

Interestingly, when I visited them after the first 24 hours had passed, they did not revalidate no matter how many times I refreshed the page. Will check them again 24 hours later.

Meanwhile, my other production deployment running Next 13.5.4 also seems to start revalidating randomly after 24 hours -- with an unpredictable interval that is definitely longer than 24 hours.

from next.js.

One week later, it seems both reproducers are successfully revalidated:

• CodeSandbox reproducer (Canary) timestamp: 1721659019626
• Vercel production deployment reproducer (Next 15 RC) timestamp: 1721659017469

Interestingly, when I visited them after the first 24 hours had passed, they did not revalidate no matter how many times I refreshed the page. Will check them again 24 hours later.

Meanwhile, my other production deployment running Next 13.5.4 also seems to start revalidating randomly after 24 hours -- with an unpredictable interval that is definitely longer than 24 hours.

24+ hours have passed, and:

• CodeSandbox reproducer (Canary) timestamp: 1721764284118 ((1721764284118 - 1721659019626) / 3600000 = 29.2401366667, it revalidates correctly)
• Vercel production deployment reproducer (Next 15 RC) timestamp: 1721659017450 ((1721659017450 - 1721659017469) / 360000 = -0.0000527778, revalidates but stale data persisted and rendered)

For the CodeSandbox reproducer, I noticed that CodeSandbox seems to keep the server (npm run start) running because I can still see the logs from last few times. I stopped the npm run start command and restarted it just now to mimic a cold start.

For the Vercel production deployment reproducer, I took two snapshots:

• 24+ hours earlier: https://web.archive.org/web/20240722145504/https://next-15-cache.vercel.app/cached/24h
• Just now: https://web.archive.org/web/20240723194919/https://next-15-cache.vercel.app/cached/24h

For the second snapshot, I took it after refreshing the page quite a few times to make sure the revalidated data persisted and propagated across the network.

from next.js.

One week later, it seems both reproducers are successfully revalidated:

• CodeSandbox reproducer (Canary) timestamp: 1721659019626
• Vercel production deployment reproducer (Next 15 RC) timestamp: 1721659017469

Interestingly, when I visited them after the first 24 hours had passed, they did not revalidate no matter how many times I refreshed the page. Will check them again 24 hours later.
Meanwhile, my other production deployment running Next 13.5.4 also seems to start revalidating randomly after 24 hours -- with an unpredictable interval that is definitely longer than 24 hours.

24+ hours have passed, and:

• CodeSandbox reproducer (Canary) timestamp: 1721764284118 ((1721764284118 - 1721659019626) / 3600000 = 29.2401366667, it revalidates correctly)
• Vercel production deployment reproducer (Next 15 RC) timestamp: 1721659017450 ((1721659017450 - 1721659017469) / 360000 = -0.0000527778, revalidates but stale data persisted and rendered)

For the CodeSandbox reproducer, I noticed that CodeSandbox seems to keep the server (npm run start) running because I can still see the logs from last few times. I stopped the npm run start command and restarted it just now to mimic a cold start.

For the Vercel production deployment reproducer, I took two snapshots:

• 24+ hours earlier: https://web.archive.org/web/20240722145504/https://next-15-cache.vercel.app/cached/24h
• Just now: https://web.archive.org/web/20240723194919/https://next-15-cache.vercel.app/cached/24h

For the second snapshot, I took it after refreshing the page quite a few times to make sure the revalidated data persisted and propagated across the network.

Interestingly, I believe the timestamp 1721659017450 came from the double rendering 24+ hours ago when I visited https://next-15-cache.vercel.app/cached/24h. The double rendering issue happened just now as well as I checked the log:

Getting user { revalidate: 86400, user: 'Foo', ts: 1721764088848 }
Getting user { revalidate: 86400, user: 'Foo', ts: 1721764088751 }

Funny enough, none of 1721764088848 and 1721764088751 was returned or cached.

IMO this is 100% a fatal bug which might affect a great number of production websites negatively. Somehow, I cannot find any other similar report. Maybe this bug is ignored by the majority as it does not happen 100% of the time, and when it happens, it might be hard to spotted.

from next.js.

Visited both reproducers again:

• CodeSandbox reproducer (Canary) timestamp (after restarting the npm run start command to emulate a cold start): 1721764284118 (stale data; screenshot below)
• Vercel production deployment reproducer (Next 15 RC) timestamp: 1721659017450 (stale data)
  • The new snapshot: https://web.archive.org/web/20240725111903/https://next-15-cache.vercel.app/cached/24h

from next.js.