-
Notifications
You must be signed in to change notification settings - Fork 26.2k
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
revalidatePath with middleware doesn't work on multi-tenant project #59825
Comments
We have the same issue, we cannot update version. Hopefully it will be solved as soon as possible... |
Here's an example of what's happening to me. I execute revalidatePath('/test2.local')
If I execute revalidatePath('/test2.local/test2.local')
It should be noted that the middleware rewrites the parameters so that the browser correctly interprets the route structure of Next.js. We are currently using version 14.0.4 |
I confirm I can reproduce OP issue and it's super unsettling, both the fact that the first revalidate on "/localhost/test" doesn't work while having a correct path, and the revalidate2 does work on "/test" despite having a wrong path. I've also tried with This feels like as some point the URL users sees is used a cache key, instead of the underlying path in the Next.js app. But surprising because this seems to affect the server cache, since the value is also not updated when opening the page with another browser. |
I have delved a bit more into this error and I am sharing it in case it helps. I have found that the tags generated for the pages are created from the request urlPathname, and this value does not take into account the rewrite of the middleware.
This causes the tags to be associated with the user's request and not with the actual structure of the project. |
I was facing this kind of issue also. I found a workaround explained here : amannn/next-intl#846 |
The "solution" that I am currently use is by using unstable_cache. With that, you are able to control the data and also the pages, even when the pages are "forced-static". You can take a look at this repository, that shows how I resolved it: https://github.com/B33fb0n3/revalidaterewrites To test it, Click the "revalidate" Button on the page "/helpi" (without query params). You see, that "somehost.com" gets revalidated and "someotherhost.com" not. Even when they are rewritten. I found this in the vercel platform example: https://github.com/vercel/platforms/ |
I have the same issue. I'm rewriting to different subfolders by mapping the request header host to When I call a server function from a server component containing revalidateTag or revalidatePath, the cache is invalidated (I see the new data in the |
After a few hours of debugging I noticed i alter the headers in my Turns out I added the user's request headers to the response 🤦🏼♂️
|
I ended up just going with revalidateTag() instead of revalidatePath() to get around this issue. |
Using revalidateTag works fine. You can assign dynamic tag to force revalidate for individual tenant. Something like this:
|
Link to the code that reproduces this issue
https://github.com/sergiolamorda/nextjs-issue-revalidatePath-multitenant
To Reproduce
First, add two domains to your local hostname, for example:
hen, execute the build and start commands:
Next, open two different tabs and navigate to http://test1.local:3000/test and http://test2.local:3000/test respectively.
Now, make a POST request to http://localhost:3000/api/revalidate, which will execute revalidatePath('/test2.local/test'). If you reload the previous tab, the content does not update.
Finally, make a POST request to http://localhost:3000/api/revalidate2, which will execute revalidatePath('/test'). If you reload the previous tabs, both will show updated content.
Current vs. Expected behavior
We're working on a multi-tenant project that employs middleware to rewrite requests, converting the host into a slug.
In Next.js 12, you can perform on-demand revalidation in the API using res.revalidate(), which only invalidates the cache for the domain where the request was made.
However, after migrating to Next.js 14, we encountered issues when trying to invalidate the cache with revalidatePath; it doesn't seem to work as expected.
Attempting revalidatePath('/domain/test') doesn't take the middleware into account and fails to produce any effect.
On the other hand, using revalidatePath('/test') results in invalidating the /test path across all domains.
Verify canary release
Provide environment information
Which area(s) are affected? (Select all that apply)
Data fetching (gS(S)P, getInitialProps), Middleware / Edge (API routes, runtime)
Additional context
No response
The text was updated successfully, but these errors were encountered: