wrangler publish is enough, but it might take some time, especially now because workers is experiencing degraded performance

Usually

It's a read-through cache

Okay thanks. I ended up just passing the details to the DO through a Worker. But I keep the word lists for the pictionary in KV

Interesting question re:

blockConcurrencyWhile

on the forums - would be great to get someone from cf to respond: https://community.cloudflare.com/t/2021-7-16-workers-runtime-release-notes/287327/3

I am no Javascript expert, but it is possible to have an async callback in a non-async function. And I can't imagine being anything different right? The thing that will happen though that he might not expect is that the value of

ret

will not be

2

, but

Promise<2>

..

That is correct—the trick is then working out how to ensure it resolves before leaving scope, because you can’t await it 🙂

You can

await (2+2)

and it's still legit four me

Because await is a no-op for no async/promise call.

I know, I was just saying: if the outcome of an operation can be either a promise or the value to which it unfolds, simply treat both cases as the former

So I have something set up with durable objects where the durable objects are websocket clients connected to an external websocket server. When I make a certain request, the dos connect to it and start listening for messages. Currently, I’m experiencing the issue that the messages aren’t always received. It seems like the dos don’t do any code logic unless there’s also a http request from a worker going on–and I think the durable objects are still alive, because the in-memory storage is still here even though I don’t save or load anything from the file system. It’s possible that I just have some errors in it (debugging is quite hard still, it runs in miniflare), but aside, is there something known like this or is it actually intentional?

Im having a really odd issue. While publishing it wont find modules anymore in a subfolder while using wrangler publish

import jwt from './jwt.mjs'

works fine, however. This fails when I move it:

import jwt from './functions/jwt.mjs'

giving:

Uncaught Error: No such module "functions/jwt.mjs".

Is there a hybrid between kv and do — in that you get the guarantee of a key existing that DO has, but not "stored" closed to where it's consumed, but stored everywhere for latency? I've got a requirement in that if I add a key, for it to be guaranteed to exist everywhere, but without the penalty. Or strategy more to stack do on top of kv, in that you query kv if not there ask do.

That's the problem. For a system like DO to exists, there has to be some latency, as it has to be able to check that no other data-centers has registered a change, before either serving a value cache in the nearest colo, or saying that the key doesn't exist. The only thing(that I can think of), that would give you something like that would be if you could add an option to wait for any changes in KV which were pending from other colos, but this would probably still add some latency to each request.

Hey.. email me with a few times for a call next week if you want. I would like to understand your use-case a bit better and to see if a thing I wrote a while back would be useful for that..

DO storage doesn't have to check the whole world for changes, it only has to check the specific datacenter where the DO lives. That's the trick -- if your data is commonly accessed in a particular geography then it can have low latency in that geography by placing the source of truth there. Generally, though, yes, it is impossible to have world-wide low latency and strong consistency at the same time. You can have low latency and strong consistency in one region, you can have low latency and eventual consistency globally, or you can have high latency and strong consistency globally...

The first is DO (with regional affinity), the second is Workers KV, and the third is DO (without regional affinity)

This seems like a bug in your code, because as you said "the in-memory storage is still here." We don't pause any of the ongoing work when you don't have a client, we only evict the object entirely after some inactivity. Are you storing the ongoing promises somewhere where they'll outlive the client request?

Is there a way to check if DO exists without creating it?

There are two ways in which a DO "exists". It can exist in memory, and it can exist on disk. It only exists in memory when a request is received, and then it stops existing there after there is no activity for a while. It exists on disk if you've stored any keys, and stops existing on disk if you delete all the keys (there's a handy

storage.deleteAll()

shortcut for this).

There's no way to check if it exists in memory before sending a request. But you can check if it exists on disk before writing, by trying to read first.

... except for caching, right? The DO will come to existence in memory close to the first worker that requested it. And that location will be cached even without storing anything?

yes, these is some caching separately, but think of that as an implementation detail. It's our job to clean up the cache.

Okay thanks. I'm just trying to see if there's a way to check if DO exists and only fetch it if it does, otherwise show up a "Create room" dialog for the user. I guess I could do that with some initialization variable in the DO

P.s. are there any known issues with DO having wrong time set? I'm sending new Date().getTime() (unix timestamp) to my client, but it seems to be off by 20 seconds

Okay, I’ll try to find the error. Are durable objects evicted if there is an open websocket connection (do is a client, not a server) but no incoming http fetch requests from other workers anymore?

Yeah, they're evicted eventually without a client connected IN to them. We have plans for more primitives to periodically wake up and do work.

It's not impossible, if it's write infrequent right, or not at all. You can ask kv for the key, if that doesn't exist you then ask DO. Or is there a way to check, or return from kv a flag of whether it exists everywhere? Kafka does that through whether it acknowledges the write after all replicas have it, or after some, or none. Basically, what I'm trying to understand is. If you want to build an app where the data is stored at the edge, from the sounds of things. DO is your only option, as kv has no guarantees. (And by app I mean, something that stores user data, some interactions, that sort of thing).

It's not a guarantee that 2 subsequent requests fly through the same DC. So before replication can happen, you can get into an undesirable state. Where one request saves a thing, and the next can't read it. Coz save went to DC_A and request read went to DC_B.

KV only caches locally, updates aren’t pushed to all colos, there are a few global replicas of the entire dataset. So after the write is done it is “available” worldwide, because if KV can’t find a local cache, it will check the closest replica. The only thing I am not sure off is when a write returns, once it is accepted in the local DC or in a global replica.