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

GET http://<URL>/slug

GET http://<URL>/slug

GET http://<URL>/slug

This calls

env.SHORTENED.get(slug)

env.SHORTENED.get(slug)

env.SHORTENED.get(slug)

env.SHORTENED.get(slug) on the worker.

For one client this results in

null

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!

johtso•6/24/24, 9:05 AM

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 …

johtso•6/24/24, 9:06 AM

If it's important that the written data is available everywhere immediately, D1 might be a better option

liorsbgOP•6/24/24, 9:07 AM

Read happens 3-5 seconds after write.

liorsbgOP•6/24/24, 9:08 AM

write and read are (throretically) from the same location since they're made from the same network.

liorsbgOP•6/24/24, 9:09 AM

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?

johtso•6/24/24, 9:12 AM

There should be a way to see where a worker is running

johtso•6/24/24, 9:14 AM

request.cf.region

liorsbgOP•6/24/24, 9:15 AM

I see it, write and failed read are from same colo

johtso•6/24/24, 9:15 AM

Interesting

johtso•6/24/24, 9:17 AM

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."

liorsbgOP•6/24/24, 9:18 AM

I see, but the key is visible when a different device on the same network calls the same endpoint

liorsbgOP•6/24/24, 9:18 AM

In other words: same worker (assumed), same region (confirmed), same key, different result

johtso•6/24/24, 9:45 AM

I guess because it's not cached so it fetched the real result

liorsbgOP•6/24/24, 9:46 AM

not sure i follow

johtso•6/24/24, 9:46 AM

"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)."

liorsbgOP•6/24/24, 9:47 AM

So reading that a key does not exist cahces the null result for that key?

johtso•6/24/24, 9:47 AM

If you check if a key exists the "does not exist" result is cached locally

liorsbgOP•6/24/24, 9:48 AM

Interesting

johtso•6/24/24, 9:49 AM

That's what it sounds like from the documentation anyway

KV - Some clients get null value for existing key.

Similar Threads

Similar Threads

Similar Threads