KV - Some clients get null value for existing key.
This is VERY weird. I've got a simple link shortening service.
On the same network, two different clients calling
GET http://<URL>/slug
This calls env.SHORTENED.get(slug) on the worker.
For one client this results in null (and 404)
For the other client the key is found successfully (and 301 to full URL happens).
Looks like this is not very frequent but has happened on more than one occasion on more than one device.
Also, this is intemittent, sometimes the request from the problematic device is successful.
Any help or ideas for what to try to debug this would be greatly appreciated.
Thanks!14 Replies
Does it match the expected behaviour? How long after being written is the key being read? https://developers.cloudflare.com/kv/reference/how-kv-works/#consistency
Cloudflare Docs
How KV works · Cloudflare Workers KV
KV is a global, low-latency, key-value data store. It stores data in a small number of centralized data centers, then caches that data in Cloudflare’s …
If it's important that the written data is available everywhere immediately, D1 might be a better option
Read happens 3-5 seconds after write.
write and read are (throretically) from the same location since they're made from the same network.
Could a plausible explanation be that the problem device is (for example) on a VPN and therefore reading from a different location to which the new key has not propagated to?
There should be a way to see where a worker is running
request.cf.region
I see it, write and failed read are from same colo
Interesting
From the page I linked "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."
I see, but the key is visible when a different device on the same network calls the same endpoint
In other words: same worker (assumed), same region (confirmed), same key, different result
I guess because it's not cached so it fetched the real result
not sure i follow
"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)."
So reading that a key does not exist cahces the null result for that key?
If you check if a key exists the "does not exist" result is cached locally
Interesting
That's what it sounds like from the documentation anyway