Applying assumptions based on memcache or databases to KV is probably going to lead you astray. You should be able to straightforwardly verify that what HardAtWork said is true - if you call kv.list with a given prefix and limit, say 20, your first request will be slower than subsequent requests. Try again immediately with a limit of 19 (in other words, a subset of your initial cached list call), and your first request will still be slower than subsequent requests, because that particular list call was not cached.

but probably better to ask the KV folks followup questions in the #874727019479437372 channel

How frequently should I expect a DO's in-memory state to be evicted on average. Does this only happen very rarely in edge case, every minute, every hour, once a day? (assuming I have an active web socket connected to the DO)

I'm running into a problem with DOs and wrangler3... I posted about it in #799437470004412476 but wonder if it might be more appropriate here: https://discord.com/channels/595317990191398933/799437470004412476/1108872750065524746 I'm wondering if my whole mental model for DO's is right... Wrangler3 doesn't like when the worker my DO is defined in doesn't have a fetch. So I added a fetch that returns nothing, and then that fetch is called when a request is sent to the DO. (instead of the DO fetch handler). My original method (no worker fetch handler) works fine in production, so I'm wondering if there is a wrangler bug or if production just works "accidentally" and that you're actually supposed to route all DO calls through the worker the DO is defined in?

you do not need to route all DO calls through the worker a DO is defined in, it is entirely possible to reference a DO defined in another worker script from a different worker script

I figured it out... I had not upgraded the wrangler in my worker folder, so wrangler 3 was trying to talk to a DO hosted by wrangler 2

is it normal or just temporary unavailable

when i try to change smart to default in wrangler it errors as well

I do love this line from the docs: > Due to the inherent limit of the speed of light...

given a key, I want to perform a "getsert" operation with KV and need strong consistency to ensure the same key does not end up wth duplicate initial values, is this a good approach? 1. kv.get(key) 2. if null, do.get(do.idFromName(key)).fetch(request) 3. using response, kv.set(key, value) the durable object class simply creates a new uuid in the constructor, and returns it from fetch.

and then I suppose I just use an alarm to delete the durable object after 1 minute?

You'd want to do the entire get/set inside the DO, otherwise you wouldn't have consistency

the value created by the durable object is fixed, doesn't change for the key after creation... in this case, it would be fairly uncommon for the key not to exist in KV so I thought I could read from KV first since that would be quicker than working with the durable object it's only when the key hasn't yet been mapped to a unique id value that I need to worry about consistency while a new uuid is being generated for the key

I see. You'd still want to do the set within the DO, and you'd need some kind of check to see that it's not already working on generating a new uuid if it gets 2 requests at the same time

I thought the durable object does the check when running

idFromName

: https://developers.cloudflare.com/workers/runtime-apis/durable-objects/#deriving-ids-from-names

Imagine two requests come in to your worker at the same time, and they both want this thing from KV. Each worker makes it's check to see whether it already exists in KV, they see it doesn't, so they both request that durable object. While only one durable object is made, they're still both requesting it, so if doing that work only once is important to you, your DO code would need to consider that

ah that's okay, I create the value in the durable object constructor (not its fetch handler). The fetch handler just simply returns the uuid that was generated. in your example, I imagine Cloudflare is responsible for negotiating where the durable object is created + ensuring only one instance is created, with the net effect being that both workers receive the same value from calling fetch on the stub it's okay if both workers then write kv.set(key, uuid_from_stub) because it'll all eventually propagate the same value

Yeah, if you do it in the constructor that should be OK I guess

race conditions like this are tricky, I wonder if there'll ever be something that can analyze your workers and tell you consistency for each read/write

hey 👋 so i'm aware Durable Objects pricing page pretty clearly implies inbound WebSocket messages are billed:

Requests including all incoming HTTP requests, WebSocket messages, and alarm invocations. There is no charge for outgoing WebSocket messages.

however, this just doesn't match up with the "Total requests" count on my DO in the dashboard, which is many orders of magnitude below what i'd expect if that were the case (it does seem like it'd be correct if 1 websocket "session" = 1 request, though) is this a case where requests (the billing dimension) != requests (the metric in the dashboard)? or is there something else going on?

I can check on that…

thank you 🎉

They should be billed, though it appears the dash metrics are a little wonky.

ok so I guess follow up question

are there any known ways to avoid/decrease/whatever the per-message costs?

from reading ^^ it seems like a lot of people here are more impacted by the connection open time on the DO instead of the per-message charge

fwiw it looks like the analytics correctly show incoming ws messages as a request for me 🤷

are you lookin' at the Compute > Total requests?