Deprecate and replace createWorkersKVSessionStorage

[aaronadamsCA]

createWorkersKVSessionStorage is dangerous because Workers KV is only eventually consistent. I think it should be deprecated, or at least very clearly marked as unsuitable for production use.

I learned this the very hard way today after a total authentication outage which turned out to be a result of a KV slowdown. Writes were taking several seconds to show up in subsequent reads, so there was a state mismatch on every single OAuth2 login callback.

https://developers.cloudflare.com/kv/concepts/how-kv-works/#consistency

KV achieves high performance by being eventually-consistent. At the Cloudflare global network location at which changes are made, these changes are usually immediately visible. However, this is not guaranteed and therefore it is not advised to rely on this behaviour. In other global network locations changes may take up to 60 seconds or more to be visible as their cached versions of the data time-out.

Visibility of changes takes longer in locations which have recently read a previous version of a given key (including reads that indicated the key did not exist, which are also cached locally).

We've worked around it for now by switching to cookie session storage, but that's not really a long term solution. I don't have an opinion yet on what to replace it with, I just wanted to get this reported ASAP.

[sergiodxa]

You could replace it with D1 backed session storage, but there's no helper for that, you will need to use createSessionStorage to build one yourself.

[aaronadamsCA]

Agreed! My hope, given Remix and Cloudflare do have a relationship, is that there can be some coordination on the right OOTB solution.

I've been wondering about Durable Objects, since at first glance it looks like you could still use KV by itself for hobby/dev projects, then add Durable Objects to meet production consistency requirements.

[r3dpoint]

'Had thought through this consequence and accepted it since sessions are localized - reads and writes to a single session are through one POP (unless a user jumps via VPN or other). Would KV work under this constraint or still result in eventual consistency?

[aaronadamsCA]

What we saw was a Cloudflare KV slowdown leading to written values being unreadable for up to 60 seconds, even for the same user on the same IP address.

This broke the OpenID Connect (OIDC) authentication protocol, because /auth would write state to KV, but /auth/callback couldn't read it within a few seconds.

Durable Objects session storage is possible, but currently painful since it won't work locally. Once Vite 6 releases the Environment API and both Cloudflare and Remix support it, it should be pretty straightforward to write a session storage adapter that uses it.

[richardscarrott]

Yeah I steered well away from KV backed session storage for this reason. I'm surprised Remix are still shipping it tbh.

We've worked around it for now by switching to cookie session storage, but that's not really a long term solution. I don't have an opinion yet on what to replace it with, I just wanted to get this reported ASAP.

One thing to bear in mind if anybody is moving from DB-backed to cookie session storage is the data will be exposed to the client as it's not encrypted (merely signed), so the security risks are significantly different -- you prob wouldn't want to store long-lived refresh_tokens etc.

We ended up implementing an iron cookie for Remix which offers encryption similar to iron-session but it does increase the size of the data significantly.

Would be great to see createD1SessionStorage out of the box.