In which case, yeah, 60s (or more in *very* rare cases) to see in other locations.
In which case, yeah, 60s (or more in very rare cases) to see in other locations.
BIt'll be queried and then immediately updated again
BFair enough, thanks!
B@Isaac McFadyen | YYZ01 do you know if there's a way to count keys? Something like the method but without returning the actual keys and just a count?
II don't believe so, no, aside from just manually calling and counting that way (which is error-prone).
BI'll have to do that then. I know that there's eventual consistency involved, but I'll need a count even if it's a rough count 
IIEasy way to test, actually - if you call multiple times in a row, if the calls all take then same time then they don't get cached, if the first is slower than the rest they do get cached.
II am wrong, just tested and KV operations do indeed get cached 
ISorry about that.
BNp, thanks for checking!
BThat's more a question for the wrangler channel I think.
BThey get cached for the exact same sets of parameters. The cache key is built from the parameters (prefix, limit, or cursor) and cached for max 1 minute (IIRC you can't customize the cache TTL currently).
BDo you know if has an upper limit somehow? After 7500 keys it won't return another , but I should have inserted more keys than that 
Mthe latency on these kv gets/puts seems awfully high no?
BIt shouldn’t. If you’re doing writes concurrently then it’s possible you cached the end of the list and need to wait a minute or so. What’s your namespace?
BWhich geographic location is this happening in and are you sure the gets are happening on a key that’s supposed to be already cached? Also is this a change in behavior or a new measurement you’re looking at
MMy bad, I thought Region: Earth meant all the data was replicated globally? I’m in Australia so if both reads and writes are going somewhere off-continent that would explain these figures
MBut I am confused about why they would be going off continent?
HKV core is US/EU iirc, so writes go there. KV reads are cached locally, in the datacenter they are read from
BCorrect. https://developers.cloudflare.com/workers/learning/how-kv-works/. So yeah, writes from Australia may take a while. The first read ever for a key will be slow but subsequent reads should be fast. The reads don’t even need to be from the same data center. Anywhere in Australia will populate the cache for all of Australia.
Workers 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 …
HOh, is that new with KV2? And how do the regions work there? Is it by country?
EThe page has been there for a long time
HNo, I mean the thing where cache is applied over an entire region? The docs still seem to imply that cache is only in a single datacenter:
[M]ore popular values are cached in the data centers they are requested from.
LWhen you say "reminder that you can only list 1k at a time", do you mean that a page is only 1k max, or that all the pages can't return more than 1,000 items?
AThat one listing is limited to 1000 keys. You can use the cursor to paginate.
LAgain, I'm not 100% clear. Let's say I have 10,000 keys that match my prefix. I make an initial list() call with that prefix and I'll get back a page plus a cursor. I can use that cursor on followup list() calls to get more pages. When it's all said and done, can I get back all 10,000 keys?
AYes. First call will list 1-1000. Second call will list 1001-2000, if you specify the cursor. And so on...
LCool. Thanks!
FHi guys, we started seeing issues with accessing (reading) values from KV. Writing works, while reading seems to fail. The failures only seem to happen when the keys contain a combination of "/ @ +". Any thoughts? Thank you!
FAlso, the keys and values are visible in the Portal, but retrieving them from the code fails.
FIf I make the key shorter and remove the special characters, it works again.
AWhat is the error you are getting? Is this happening consistently?
FI can reproduce it 100% of the times
FNo error, just that the returned value is null
AIs this through a KV binding?
Fyes
Fboth storing and reading the value
FI could give you a sample key
Fhere is one: "registrationChallenge/mylongname.something+test1@gmail.com"
FI can see the key and value in the portal, but the code when trying to read it receives null.
FIf I change it to "registrationChallenge" (just to test), it works
AHmm, I am not able to reproduce this. Could you share the code snippet?
F
Fand this is for setting the value
F
AJust as a sanity check, could you please try logging the key just before the statement?
Aand also before the put
Fyeah I did, copy and pasted in Notepad and compared them 
FAnd this is code that worked until a couple of days ago. I checked everything and nothing was changed in the code in 2 weeks. The only change that we did do was to switched to a paid plan (we were on the free one before) - which should not be causing this
FIf it works for you, I could continue investigating on my side and see if I missed anything.