Hi, running into some weird eventual consistency behavior with KV - when updating a KV key value pai
Hi, running into some weird eventual consistency behavior with KV - when updating a KV key value pair (via the API), accessing it via worker seemingly randomly returns the old version and switches back and forth to the new updated one. Any ideas? cacheTtl used to be set to 5 minutes, but this issue has been apparently occurring for the past 24 hours
14 Replies
when looking at the KV dashboard, the correct version is present there, but workers still return the old version, even after several hours
Hello.
Did u solve this issue?
@Jax Please DM me the details of your KV namespace
I'm using KV to cache browser screenshots as described in this doc: https://developers.cloudflare.com/browser-rendering/get-started/screenshots/
In that doc, the
expirationTtl for the screenshots in KV is being set to 24 hours. My ideal would be to make the expiry much longer (e.g. 1 month), but with an implementation like an LRU cache where the TTL would reset whenever the value is read, so that only keys that haven’t been read for 1 month are evicted. Is there a way to accomplish something like that with KV, or is there another product that would be better suited for that kind of implementation? I did a search in discord and found this message, which suggests that KV’s expiration TTL isn’t the way to achieve this, but then because reading a value with a cacheTtl parameter resets any previous cacheTtl from a previous read, I thought there could be something there.Is there any plan in cloudflare to implement "kv but without cache"? I know I can use D1 / Durable Objects in some scenarios, but they both have some trade-offs, and to bypass the trade-off requires too much effort.
Why not just use R2?
A very interesting alt method. I may consider this, though I doubt whether it can handle frequently CRUD.
It can handle it a lot better then KV does. KV is eventually consistent and should only be one write per key per second
https://developers.cloudflare.com/r2/reference/consistency/ R2 is read after write/strongly consistent.
Although it may be worth mentioning: Why did you say Durable Objects has some trade offs you don't like? R2 is backed by DOs for metadata and then stores the actual objects elsewhere
For my next purpose, I want to use it for de-duplicate. Each of my ID is 128-byte, and the durable objects' size limit is 128KB, so only 1k records will exceed the limit, which will happen in less than one second. Even the durable objects' with SQLite backend can be filled with only 16k records. Since I need to store at least 7 days data, it's far from my need.
Oh, that's first time I know that some part of KV is backed by DO.
But, from the document, I don't find any related to the cache time around the metadata in KV. I guess the cache policy is the same as value, right?
ahh ok, yea the max key size for R2 is 1,024 bytes and there's no bucket max
Oh, that's first time I know that some part of KV is backed by DO.R2 is, not KV
But, from the document, I don't find any related to the cache time around the metadata in KV. I guess the cache policy is the same as value, right?For KV yea should be the same, but that document I linked was about R2, not KV
hi. beginner here. i'm having trouble with accessing KV from a worker. i did the binding but keep getting errors
keep getting "Property 'get' does not exist"
in the worker code, should i refer to the name or to the value of the binding?
would appreciate any assistance
Whatever you set
binding to is what you access in your env, ex: https://developers.cloudflare.com/kv/concepts/kv-bindings/#access-kv-from-workersCloudflare Docs
KV bindings | Cloudflare Workers KV
KV bindings allow for communication between a Worker and a KV namespace.
If you're using service worker format
addEventListener('fetch',... (migrate to module workers is recommended) then it's a global varif i have that, which should i use for .get and .put, the name or the value?
