You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Brief Description of the Bug
When using the App directory, calling revalidateTag will delete all entries with the specified tag. When the user browses a page that was tagged with the tag, the page is rebuilt during the request, causing a delay for the user. I would have expected the page to be rebuilt in the background after the request has been served, as happens when using the built-in CacheHandler.
Severity
Major
Frequency of Occurrence
Always
Steps to Reproduce
Navigate to a page '/test' with tag 'xyz'
call revalidateTag('xyz') in an api endpoint - this deletes the cache entries for the tag
Browse to '/test' - the page is rebuilt inline rather than in the background
Expected vs. Actual Behavior
I would expect the page to be rebuilt in the background and the user who initiated the request to be served the stale content.
Environment:
OS: MacOS
Node.js version: v20.10.0
@neshca/cache-handler version: 1.0.5
next version: 14.1.0
Attempted Solutions or Workarounds
Looked into how the stock CacheHandler works - it seems that we would need to replicate the behaviour in FetchCache and FileSystemCache?
Impact of the Bug
We would like to containerize our app, building on a remote CI environment using a shared cache, and have ready-to-run testable Containers as built output - and this is a blocker for us
When the user browses a page that was tagged with the tag, the page is rebuilt during the request, causing a delay for the user.
This behavior is not a bug. Native Next.js cache works the same. It makes sense to me because on-demand revalidation is a manual process.
It is also worth mentioning that pages from the Pages Router are updated synchronously on res.revalidate(pathname), and CacheHandler can not alter this. As a result, such pages are always fresh after revalidation. I think that the App Router pages inherit this aspect of on-demand revalidation.
Activity
better-salmon commentedon Mar 11, 2024
@joshudev hello!
This behavior is not a bug. Native Next.js cache works the same. It makes sense to me because on-demand revalidation is a manual process.
It is also worth mentioning that pages from the Pages Router are updated synchronously on
res.revalidate(pathname), and CacheHandler can not alter this. As a result, such pages are always fresh after revalidation. I think that the App Router pages inherit this aspect of on-demand revalidation.I'm converting this issue to discussion.