Data cache not functioning since 3.3.1

[maciej-baruch]

Hey.
I noticed that my data cache stopped functioning ever since I upgraded to 3.3.3 (from 3.2). I went through the code, debugged some, did some testing by myself and I feel like I found an issue.
When an event is extended in the 'request' nitro hook, any changes introduced to the event are lost, only event.context changes persist:

FYI - I am doing SSR in SWR mode (no pregenaration).

Apparently Nitro might create new events through lifecycle and it won't be able to copy over keys that it is not aware of.
This might also happen in middlewares.

Would you welcome a PR that puts stuff on event.context instead of just event?

[dulnan]

I was under the impression that whenever a new event is created (for example when using $fetch in a component to get some data from a server handler) that the hooks that add the cache context are also called again. But I could be wrong here.

Originally, the context was actually set on event.context but I changed this in #65, because it was leaking across the lifecycle. For example, when using useRouteCache() inside a server handler that is called from within a page component, you would actually set the cacheability for both the server route and the page itself, since it's a single context object that is now shared in both cases.

Could you tell me in what scenario exactly the data cache was not working? I assume it's not generally not working, right? The data cache feature is covered by several E2E tests; I would be quite shocked if it works in tests but doesn't work in actual installations.

[dulnan]

I updated to the latest Nuxt version in the module and ran the tests; and indeed a ton of tests started to fail, including one's for the data cache. So the data cache (and likely all caches) are broken. Not sure if its related to event.context, but I will investigate and hopefully find a fix.

Turns out this was just a configuration error in the module's tests. After fixing, all tests are green.

I assume it has to do with using the swr route rule. I will try this out now.

[dulnan]

I can reproduce the issue by using swr: true on a route that uses the data cache. Let's see if there's a way to fix this without breaking non-swr behaviour...