Do DOs crash if they error, I guess thats the question. I have observed the code below would correctly return an error to the worker that forwards it to the client. Following the chat room example this is inside the User DO.

javascript
class User {
  async job_new_transcode(request) {
    const json = await request.json();
    var {now, uuid} = uuid32hex();
    const job = {
      uuid: uuid,
    }
    await this.storage.put(`job:${uuid}`, job)
    this.broadcast_new_job(job)
    return new Response(JSON.stringify({error: "ok", uuid: uuid}), REPLY);
  }

  broadcast_new_job(job) {
    this.sessions.forEach(session => {
        if (session.this_does_not_exist.crash) {
        }
    })
  }
}

if broadcast_new_job is made async, and we dont await the call. It still crashed but no error is reported. In both cases the DO does not stop running.

is there a way to get all DOs of the same class?

that are created/exist

or a way to make DOs join groups

that you can then lookup all members of the group

my usecase, each user is a DO, i want to get all users of the system

I'd create a new DO just for those lists

Hey, how do I access environment variables (rather secrets) in a worker script? Usually they're exposed just as a variable and I could use them in the past, but now I'm getting an

undefined

back. I had this working prior to testing out durable objects and usually it worked just fine

I think everything is exposed via the passed in

env

in a durable object >

js
>   // In modules-syntax workers, bindings are delivered as a property of the
>   // environment object passed as the second parameter when an event handler or
>   // class constructor is invoked. This is new compared to pre-module workers,
>   // in which bindings show up as global variables.
>

Thank you! So I'd put this in the

constructor

part then to declare it?

for the worker itself it'd receive it in the fetch I believe

async fetch(request, env) {

for the DO yes

constructor(state, env) {

It seems to work, need to make some more adjustments. Getting closer 🙂 Thank you!

I guess I'm confused by what you mean by "does not stop running". Do you mean a subsequent request to the Object succeeds and sees the same in-memory state? I'd want @User or someone to confirm, but in your example you make an async call without awaiting it, which won't execute before you return a response to the user. Once you return a response, we'll cancel outstanding tasks. This means your crashing code will never run. If you use waitUntil to force the runtime to wait for the task to complete, you should still see the crash (not sure if waitUntil support in modules has been released yet).

But it gets complex with removals. Actor models like erlang and akka have concepts of a monitor, where if a process(DO) dies, the processes monitoring it get a message. With this it would be sane otherwise if you have 10b user DOs, and a user deletes itself without notifying the DO holding the list, youl need to walk all the 10b checking which one died.

By does not stop running, I mean the other connected websockets to the DO do not drop. If I remove the crashing part, the function executed correctly even tho the response was returned already. It seems non awaited async functions hang around after the request has returned a response (regular post in this case)

Is there documentation describing the DO sleep/quiescence timing?

if I'm not using long-running WebSockets or anything like that, how long after the last HTTP GET/POST request does the DO stop billing? Am I only billed for the number of milliseconds spent responding to the request? Am I billed for the number of milliseconds that the RAM is occupied? If the latter, do I have any control over how long it remains in RAM before it's killed?

afaik you are only billed for the request processing time, you dont need to worry about when the DO is stopped or what happens in between of your requests

Hi, when using Durable Objects with TypeScript, should I rather use

typescript
async handleRequest(request: Request, env: DurableObjectEntries<DurableObjectNamespace>) {
  const id = env.COUNTER.idFromName('Foo');
  // ...
}

or

typescript
interface Environment {
  [key: string]: DurableObjectNamespace
}

async handleRequest(request: Request, env: Environment) {
  const id = env.COUNTER.idFromName('Foo');
  // ...
}

? Is the interface

DurableObjectEntries

intended for this use case at all?

It's better to specify your own

Environment

or

Env

interface, because you might want other bindings eventually. Like an actual env variable or a KV namespace

what would be the correct way to have a tick inside a DO if there is atleast 1 connected websocket to it? a setTimeout?

or the waitUntil?

I've been checking out the webpack example: https://github.com/cloudflare/durable-objects-webpack-commonjs/blob/master/src/index.js

How can I access the

event

in there?

I don't see any references to

respondWith

with

event

.

?

oh you mean how does it return a response?