well that's good to know

I think people would appreciate seeing that documented somewhere 🙂

@User Hi - and good morning from Japan. Thanks for those ideas. Scala, Kotlin and the like seem to be full blown languages that I might explore later as I get more settled in my project. I'm needing something right now to slow down the procrastination bleeding - I'm most comfortable with Svelte - but I was also hoping for something a bit more static - I'm going to check out rescript which is the one I think you and @User were referring to earlier.

okay - a little be scarry. I just tried out rescript. I thought it had errored or something because the terminal returned control to me too quickly after running 'npm run build' - but then I realized that it actually built the project. You have my attention now 'rescript'.

I verified this works, for a client in Tokyo the worker and DO are running in

KIX

. Thanks! However, I am noticing a lot of latency (~440ms) from Los Angeles to that DO. My existing infrastructure running on GCP gets me ~120ms (with a dispatcher [similar to worker] in Oregon, and a reflector [similar to DO] in Tokyo). Is there a way to make it faster?

Is that the first fetch to a new actor identified by a string name? Or is that a fetch to an existing actor? Or is that latency of something like a websocket send on an already open connection?

The latter. Roundtrip latency of sending a message via open websocket to receiving message in response.

Hmm. Was the websocket established as the first fetch to a new actor?

Actually, the first fetch from a given PoP to a named actor? I’m curious if it’s different if you reconnect from the same PoP

I expect it is

(If you’re using named actors and not unique system generated ids)

"named actor" is a "durable object" yes?

I'm using the named ones, yes, not unique

Sorry, I’m mixing internal language and on my phone hah. I’m only talking about DOs yes but what I mean is how you’re naming them

OK, if you can try a new request from the same location I’m curious if it improves. I’m pretty sure I know what’s going on and can explain better in a bit

Oh it does!

~130ms now.

That's much more in line with what I'd have expected. – So what's the problem with connecting to a "fresh" actor?

Named objects are relocated near their original caller on creation, and that relocation is cached (per PoP). So until a PoP knows where to go, they go to the "original" PoP and get proxied to the proper location. This is of course internal implementation details, and subject to change. Websockets are the worst effected by this, since that single connection may be longed lived, even though now Vancouver knows all future connections should go directly to Tokyo

If your use-case fits with unique ids then that's the best fix in the very short term. Otherwise you could do something hacky like await a simple ping fetch before you establish a long lived websocket (this would of course make your initial connection setup time worse...)

We'll have to think about this internally, it is a drawback of proxying, but we also do that for other reasons

Hmm, interesting. Can't use unique IDs. The ping fetch sounds doable. The next request would be guaranteed to not be proxied?

Not guaranteed since it relies on a cache, but incredibly likely

I don't like recommending hacks that users have to implement (since we'll find a way to make this better, I hope), but you could also do a little WS handshake dance and if latency is >150ms you retry getActor get/fetch once? Or something?

I can't get "actor" out of my head, sorry

No problem

You should make a new stub with

.get

between the fetches and/or reconnection

Will try. Not the highest of my priorities, but I got curious. And it might be better before you come out of beta I guess 🙂

Hi, I have an issue where I created a test worker and a test durable object class. Now I want to delete the worker. However, this fails because it says a durable object is still associated with the worker. So I tried

wrangler publish --delete-class ClassNameHere

, but then I get the error message

Cannot create binding for class ClassNameHere because it is not currently configured to implement durable objects. Did you forget to apply a --new-class migration to it?

Any ideas what the solution is here?

If anybody needs this, the answer is that wrangler seems to have some sort of bug in it that doesn't let you do this easily, as the documentation suggests. So you must do it directly from the API like so:

bash
GET https://api.cloudflare.com/client/v4/accounts/{accountID}/workers/durable_objects/namespaces

This will return you:

json
{
  "result": [
    {
      "id": "{yourDurableObjectId}",
      "name": "someName",
      "script": "someScript",
      "class": "ClassNameHere"
    }
  ],
  "success": true,
  "errors": [],
  "messages": []
}

You then run:

bash
DELETE https://api.cloudflare.com/client/v4/accounts/{accountId}/workers/durable_objects/namespaces/{yourDurableObjectId}