how long does a DO stay around after the last request? 30sec?

(with 0 websockets connected)

Also whenever trying to use I get "Error: unknown field

upload

, expected one of

command

,

cwd

,

upload_dir

,

upload_format

,

upload_include

,

upload_exclude

, `watch_dir`"

ok well I updated to latest wrangler now I get

error: Found argument '--new-class' which wasn't expected, or isn't valid in this context

You need https://github.com/cloudflare/wrangler/releases/tag/v1.16.0-durable-objects-rc.0 for durable objects

ah cool thanks I thought you didnt need those type builds once 1.16 was released because of what the template said

is there anything like https://docs.datadoghq.com/serverless/installation/nodejs/?tab=serverlessframework for cloudflare workers

it seems the main problem is all the nodejs statsd clients send raw TCP or UDP, they need to be wrapped in HTTP / aggregated on the side of the serverless invocation

not sure if a statsd client exists that integrates directly with something like datadog passing over their HTTP endpoints

i am a bit confused by the fact that the durable objects fetch function does not have a FetchEvent but a Request parameter only. is this because the durable object worker is not accessible from the outside? is it possible to read/write from/to KV within the same worker e.g. with getAssetFromKV which requires an FetchEvent object as a parameter?

DOs can only be accessed from another Worker, not directly via an HTTP route. I'm not sure I'd say that's why they don't receive a FetchEvent. Either way it looks like

getAssetFromKV

only uses the FetchEvent to grab the request and to use waitUntil, so it could be adapted to work from a DO and hit the same KV objects.

so to be clear: is a durable object the class instance only or is it the worker with the live object that references it? in other words: is it just the class instance being referenced from the toml file or also the worker instance the durable object is bound to? i.e. do you need two workers, one facing the public internet that is talking to another one which interfaces with the durable object class instance? or can the worker facing the public internet talk directly to the durable object? i am asking since we have code that's expecting the FetchEvent as a parameter but I am not sure if the switch to esm syntax is the cause why the FetchEvent from the parameter is missing or its because this is a durable object worker that receives different parameters (we're migrating an existing worker to additionally use DOs)

i think i'm mixing up this section with DOs: https://developers.cloudflare.com/workers/learning/using-durable-objects#instantiating-and-communicating-with-a-durable-object so if i understand correctly we have to migrate our worker to the new esm syntax and there is no FetchEvent anymore? is there some documentation about what to use instead if you rely on this object? i assume you can get some info from the env param?

Actually wondering the same thing. I have a worker using the new syntax "export default { async fetch ..." which is at some point making use of a DO class in a separate file. Can't seem to get the FetchEvent in that worker to use waitUntil etc.

Any "normal" Worker can have a binding to access a Durable Object class, so you just need the 1 Worker accessible via an HTTP Route and it can access the DO instances. My guess is the FetchEvent bit changed because of the ESM module switch, but I'm not sure.

i see, that makes sense. so this is orthogonal to DOs in a way. is there some documentation of how to migrate a worker to ESM?

I am new to durable objects, I would like to know about coordination. if I access the same DO from two different worker trying to persist the modifying state, will the last value be stored in persistent layer & loaded in both DO instances?

I don't know of any documentation specific to that, the

getAssetFromKV

code you mentioned only used the

request

and

waitUntil

fields, which are both available to DOs (the latter is on the

state

provided to the constructor) https://developers.cloudflare.com/workers/runtime-apis/durable-objects#durable-object-class-definition

There is only one instance of a specific Durable Object, so I'm not sure I follow the end of your question. There is no "both" 🙂

thanks, i think that clarifies the confusion we had. so basically we just migrate our worker to the new syntax first. 👍

since we also switched from webpack to rollup and are using typescript we were not sure why we saw some strange runtime error

There is apparently a 3rd parameter on

fetch

(context) that contains a

waitUntil

and other fields. TIL

^ also @User

Oh wow, thanks! 😅

So all computation would be in worker where DO is loaded by fetch support I believe. If this is the case, would local processing give different results?

I don't think I understand what you mean by local processing. Think of an individual Durable Object instance as a single server that all requests (to that instance) will go to. So a request from Tokyo and one from Dallas might both end up in Amsterdam if that's where the object happens to be running at that time. The entire purpose is coordination

thanks

where did you get this info? from the docs?

From my coworker @User 🙃 -- I'm not sure if that is clearly documented yet

It’s a very recent addition — mentioned in the runtime release notes, but hasn’t been documented yet.