this code has been running fine for almost a year, then suddenly tonight its being weird, which make
this code has been running fine for almost a year, then suddenly tonight its being weird, which makes me think its a KV issue
ICan you send the KV namespace ID please? (it's fine/safe to share publicly) Me or someone else can try and escalate if we have the chance.
Akv namespace:
account:
af574b5f161d4d3c938fae885549b417account:
f55b85c8a963663b11036975203c63c0IAnd when you do a
get on the key are you specifying a cacheTtl? If so, what is it?
Ainitially I did not, however as a troubleshooting step I tried setting it to
60 which seemed to not make a differenceIThe fact that the dashboard is also sometimes not returning the keys makes me think it's not your code, so I'll go ahead and see if I can raise this.
Athe issue is also occurring across two different workers if that helps
Athe issue seems to be happening with the
2025/03/21:snippet and 2025/03/21:videoId keys. Other keys that were written around the same time (2025/03/21:mainShowStart would have been written within a few minutes of the others) do not have this issue oddly
Aim not sure if its the same issue, as listing in my dashbaord appears to work for everything except for these two keys
Oah interesting. still wanted to share it incase it helped
Athank you! 
IOK I escalated this, I'm heading to sleep but when/if CSUP gets to it I'll ask them to communicate here directly. No promises on timeline though.
Athank you. i'll see if I can work around it for now, as ive got things that depend on reading this data that I want to be processed ASAP
IDo you know around when the keys were written?
Aa few hours ago, i can get a rough time 1s
Ait would have been somewhere around this timestamp:
2025-03-21T23:56:12ZAprobably before, but might have been the same time. i don't remember exactly what order theyre written, but i can look if important
II'm wondering if it would perhaps have occurred during this incident earlier https://discord.com/channels/595317990191398933/895794943182909470/1352765245877391421, I didn't think KV and R2 were connected but perhaps they now share some infra internally that might have failed?
INo don't worry, just wanted to get an approx. timestamp.
Athe earliest it could been written is 23:45 UTC
Awhich it looks like the r2 issue was resolved by then
Aplease ping me if there is any movement on this 
Ait looks like it might be fixed now? its been showing consistently the past few minutes
CHey there, thanks for the update on this. Are you still seeing the issue with the KV keys that you were initially reporting?
Ait looks like those keys I mentioned are still sometimes not showing up in the dashboard.
but I have a cron task that collects those keys into a single one, and that appears to have read them correctly this time so its no longer interrupting my application
but I have a cron task that collects those keys into a single one, and that appears to have read them correctly this time so its no longer interrupting my application
Aalso i realized I forgot to mention this before, but those keys also have an expiration set (15 days)
AIf it helps, here is what this kv namespace is for:
each of those keys with colons are "fragments" of an event. they are fragmented because each piece of info is available at different times and I need to record them. that cron then combines them into a single key after the event for easier reading, so those fragments get an expiration ttl of 15 days (enough so that I can diagnose things if something goes wrong with the collapsing, and small enough so that they don't stick around forever wasting storage)
each of those keys with colons are "fragments" of an event. they are fragmented because each piece of info is available at different times and I need to record them. that cron then combines them into a single key after the event for easier reading, so those fragments get an expiration ttl of 15 days (enough so that I can diagnose things if something goes wrong with the collapsing, and small enough so that they don't stick around forever wasting storage)
Athis part of the application was made before D1 existed, otherwise I probably would have used D1. Once D1 read replicas are launched, i might consider migrating this specific namespace to d1 instead, since that would probably better fit this usecase
Aeven though its no longer effecting my application, lmk if theres any other info I can provide if you want to look into preventing this from happening in the future
TWe're looking into how to resolve this, it seems like some routing was changed up which is making it take more time for you to see updates in the dashboard
TI am having issue with KV.
I query a record from D1 Database, it took me 15ms, then I cache that record as json in KV.
I read that record from KV with record id, so I expected it should be faster than D1 but it actually took me 500ms, way slower.
Am I doing it wrong?
I query a record from D1 Database, it took me 15ms, then I cache that record as json in KV.
I read that record from KV with record id, so I expected it should be faster than D1 but it actually took me 500ms, way slower.
Am I doing it wrong?
T
TI finally found a bug that continuously write and invalidate the cache. MY BADDDDDD.
CRead status to show this many Not Found results?Depends entirely on how you're calling KV. If you're using it to serve static assets and people are requesting non-existent paths, not too surprising. If you have a manifest or something in front, making it so every KV get request should always exist, could be a bug in your code.
Your p50 is really high there, how are you using KV? Could you increase cacheTTL/hit the same keys more?
TKV is a global key-value store. If there's not heavy traffic on your keys, then they won't be getting cached in all of the Cloudflare locations. When this is the case, then it needs to fetch the result from the central stores for key-value data. See https://developers.cloudflare.com/kv/concepts/how-kv-works/ for an explanation on this
Cloudflare Docs
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 data centers after access.
SCan we store complex JSON in KV as a value? I have a json that’s 4,5 levels deep and need to know if that’s possible with KV.
IAt its core, KV stores bytes so any value (including JSON) that can be serialized/deserialized as bytes can be stored in KV.
INote that in contrast to JSON-oriented databases, KV just stores the bytes. You can't query on nested JSON fields or anything because KV has no idea it's JSON, it's just storing the content.
SThat’s good to know, do you have an example showing json value into KV? How do I translate the object into a Value?
SThat’s not an issue. I’m planning to use the KV as a cache to avoid hitting network excessively
Oif ur JSON is small enough (and since you're working with JSON) you can/should probably also insert it into the metadata https://developers.cloudflare.com/kv/api/write-key-value-pairs/#metadata
https://developers.cloudflare.com/kv/api/list-keys/#optimizing-storage-with-metadata-for-list-operations
https://developers.cloudflare.com/kv/api/list-keys/#optimizing-storage-with-metadata-for-list-operations
IThe
put accepts any string, ReadableStream, or ArrayBuffer so you can just JSON.stringify it: https://developers.cloudflare.com/kv/api/write-key-value-pairs/SIt’s Pirate weather data: https://docs.pirateweather.net/en/latest/API/#example
I hope there’s a way to cache it?
I hope there’s a way to cache it?
SI’ll try this one out tomorrow. Serialising/ Deserialising from ReadableStream should be fine
TYou should probably store it as a string and then read it with json. Check out the new KV examples, this is one where a list of translations are stored https://developers.cloudflare.com/kv/examples/workers-kv-to-serve-assets/#:~:text=Default%20to%20English-,const,-translations%20%3A%20%7B (could have more depth there, as much as you want)
Cloudflare Docs
Example of how to use Workers KV to store static assets
