-
Notifications
You must be signed in to change notification settings - Fork 161
Fix issues with revalidateTag/revalidatePath #470
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
🦋 Changeset detectedLatest commit: 9463e64 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
wow @conico974 did you really just fix this today aswell 👏 you are such an inspiration! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
revalidateTag
for next 15+revalidatePath
not clearing the fetch cache ( When doing arevalidatePath('/whatever')
, all thefetch
orunstable_cache
inside this route would return the cached value instead of refetching )There is a few things that we need to think about:
Right now the fetch cache in OpenNext works in a different way than in
next start
to take full advantage of DynamoDB.In
next start
for every get to the incremental cache, they check for every tag used in this get ( and this include layout, page and fetch cache tags ), we only check given the path which entry in DDB is newer, and if so consider the cache entry stale. This mean we can make one single optimized query to DDB instead of either multiple get or an expensive scan/query.On the other hand the current DDB solution requires a lot more write than the default cache included in next ( They only write on
revalidateTag
)I think in the future we should probably support the 2 type of cache ( The next cache could be easily implemented in SQL for example, and it's way better to do it that way in SQL than the DDB way ). Even in DDB, someone barely using on demand revalidation would benefit from a next type of cache.
The other thing is, we may want to allow the
revalidatePath
to not clear the fetch cache, this gives a lot more flexibility and would allow to invalidate only what's really needed ( But that's not how next works right now ). Not sure if that's something that people may want. We could introduce an env variable that if set would make it work like right now ( it's still possible to clear the fetch cache individually usingrevalidateTag
and some custom tag )