SSR prefetching (hydration/dehydration) with NextJS and client side routing to the same route.

[callumbooth]

Describe the bug

Not sure if this is a bug or if I'm doing something incorrectly but when using SSR hydration/dehydration prefetching based on the docs, the first request will set initial data for a query correctly, but when routing to the same route but with a different param the cache isn't updated with the new prefetched value.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://ctwew.sse.codesandbox.io/set1
2. Open up the dev tools and see that the data returned from getServerSideProps and the data displayed is the same.
3. Click on toggle set, this will perform a client side route change and will call getServeSideProps as an api call.
4. You will notice that the data onscreen will still have "dataSet: set1", the url will be "/set2". However if you check the console you will see that the data contains "dataSet: set2"

Expected behavior
I would expect the data from getServerSideProps to update the cache and the components using the data to be rerendered with the correct values.

Screenshots
https://codesandbox.io/s/amazing-paper-ctwew?file=/pages/%5BdataSet%5D.js

Data returned from getServerSideProps on the initial page load.

Data returned from getServerSideProps on the route change.

Desktop (please complete the following information):

• OS: macOs
• Browser: chrome
• Version: 2.13.1

Additional context
I did notice the force option for the prefetch query options and have tried it with "force: true" but that didn't work either.

[tannerlinsley]

@Ephem might know more about this while I noodle on it.

[Ephem]

@callumbooth Great writeup, and wow you found this quickly, I realized it myself only a few hours ago. I'll explain the cause it in detail when I'm at a computer.

@tannerlinsley This is the updatedAt-thing I mentioned on Discord.

I do have a fix in mind, will try to find the time to implement it asap.

[tannerlinsley]

Awseome!

[Ephem]

Okay, so the slightly longer version/explanation of this is that there are two prerequisites for this to happen:

1. Query with same key gets fetched twice
2. The second fetch comes in through a hydrate

So to be clear, if that example had the url in the query-key, the first toggle would succeed (because the key with /set2 is different from 1), but on the second toggle back to one any more recent data from the server would not enter the cache. I'm pretty sure this is what that reproduction was meant to show, but I want to make this part clear for anyone reading along.

What the above means is in essence that this mainly effects Next.js getServerSideProps.

The reason for the bug is that when hydration was first started to be implemented, we didn't hydrate updatedAt or base any staleness etc on that. This meant that the only safe thing to do was to never hydrate any queries that were already in the cache, since we didn't know if queries coming in via a hydate contained newer data or not. When this changed and updatedAt became a thing, I kind of forgot that this was a problem we had in the first place and forgot to implement it. 😬

So the fix is to make the default behavior that when hydrating, we look at updatedAt and if the data in the query that is being hydrated is newer, we overwrite the existing query in the cache.

[tannerlinsley]

🎉 This issue has been resolved in version 2.15.4 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[callumbooth]

I can confirm the issue is fixed, thanks for pushing a solution so quickly.