this does not compile

not always, the true location of

idFromName

objects is cached in each PoP

is there a way to test for the existence of a DO by id? I'm generating via

idFromName

from a user-friendly char[5] code and I want to reroll this code if it's already in use. I suppose I could have my own DO that tracked these, but it seems like re-inventing the wheel.

Guys, is there any ETA when you are coming out of Beta. 6 months, a year?

You could set an isInitiated flag in your DO and when you get it by id check if it's true. I guess it should work. But there probably should be a better way

yeah, I'd started to write that as another option but deleted it 😛 The point where I generate the code doesn't need to deal with the DO itself currently, but it could without too much pain.

followup on this. Is there a way to have

fetch

and

scheduled

handler in the same worker if ES6 is used?

As a rule we don't announce roadmaps unfortunately. There are just way too many variables that can influence them. Especially something as new and cutting-edge as Durable Objects..

I have two primary questions at the moment: a) if DO relocation becomes a thing, how will it feel? Will it be automatic, or will DOs have a .moveToCurrentRegion() function? b) does DO data hope to be as reliable as Workers KV (as in practically 100%)?

Is there a way to list all object IDs/names? Something like

OBJECT_NAMESPACE.list(): string[]

?

not currently, a way to list is coming. for now you'd need to track object IDs in an external system like Workers KV (or another DO object)

I can't speak to whether we'd ever allow manual relocation or not. We do offer jurisdictions but they aim to solve a specific problem: https://developers.cloudflare.com/workers/runtime-apis/durable-objects#:~:text=Durable%20Objects%20can%20be%20created,to%20comply%20with%20local%20regulations.&text=The%20jurisdiction%20constraint%20only%20controls,itself%20runs%20and%20persists%20data. and DO data is intended to be durable forever (it is replicated and backed up, of course). that said we don't necessarily make any promises during the beta period, AFAIK

Is there a way to unbound the execution time of a DO request? It seems when I do a setTimeout that calls another setTimeout, when some kindof CPU limit is reached, the setTimeout dies and fails to proc

I am trying to do a tick inside a DO

how can one have a cron callback and fetch in the same worker using ES6 (so DOs are callable?)

i think it doesn't compile because you're missing a comma. object literals require them, class definitions don't.

But what object is this with a function inside? Never seen this documented on js. Il chrmeck tom ty

Yeah you need a comma, and thats just normal JS object syntax it always requires a comma to define a new variable/function

that or

see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Method_definitions

Any chance the list DO API will support a start/end prefix like KV so it can be used as a secondary index to find DOs? As currently those tracking DO manually via KV have that option.

I've got some websockets attached to a DO, using basically the chat demo. I connected from a phone and went into airplane mode to check the disconnect detection. There's no error being thrown by

socket.send(message));

and the DO seems to still consider it connected after about ten minutes now. Is the worker still alive and keeping the ws open? Is Cloudflare sending ping frames to test the connection?

Oh, it just disconnected now. That's way too long...

I just tried again, that was over 17 minutes and over 200 messages after the point that connection should have been dropped.

Hey, sorry this took a while to answer. Modules currently aren't as well documented as we'd like, but in the meantime here's the proper syntax

export default {
    async scheduled(controller, env, ctx) {
        // controller has scheduledTime and cron properties like ScheduledEvent
        // env has KV bindings, DO bindings, secrets, config vars, etc
        // ctx has waitUntil()
        
    }, // need commas between functions
    async fetch(req, env, ctx) { /*...*/ }
}

I've just run a few dozen tests, and 17/18 minutes is generally how long the zombie connections last. The number of messages they're meant to be receiving doesn't seem to matter.

You need to implement your own ping/pong. Tcpstack on phone I guess doesnt send rst packets on airplane mode turning on

that's an option, of course, but the demo from Cloudflare is demoing functionality that doesn't work and I don't know if the CF guys know that

https://github.com/cloudflare/workers-chat-demo/blob/b80a563527f549e99bef6548da64406a1326786a/src/chat.mjs#L412 <-- this never throws so the quitters code is never run

Good catch!