Is there some known issue with DOs simply hanging/not responding every so often? My code creates a new DO for every request and then inside the DO sets up a websocket that simply echos everything back. I suspect that 40% of the time (especially just after a deploy) the websocket request simply hangs (and from the logs it seems to be inside the do)

Just had the issue again: last new code deploy was more than an hour ago. It connects fine. I refresh the page, the websocket infinitely hangs. Couple of minutes later, works fine again

Hi Does anyone know how to get the static assets manifest in my worker when using durable objects alongside workers sites?

How is DO pricing going to work?

you can publish multiple files separately, but it's often still nice to use a bundler so you can resolve dependencies in

node_modules

and minify your code

also, things like wasm modules are uploaded as separate modules

nice, thanks Matt.

Do you have Type package support the WebSocketPair type - struggling to get that to resolve?

Check out the issues on the types repo, theres a snippet there

perfect, thanks

converting my script worker over to a module worker (now that

waitUntil

is available), and noticed that the incoming

request.cf

is not available for module workers, even for non-DO calls. Is this a known issue?

Yes... we are having a bit of a debate about whether to change the way

cf

is delivered and so didn't want to make it available in modules yet... but I think we might give up and leave it as it is.

Ah ok, thanks - I'll hold off on the conversion for now then. Looking forward to seeing it back in there in any form. If one path (external calls) differs from the other path (do calls) enough to have different type signatures, perhaps the do fetch method should be called something else

this isn't a stateless vs. DO difference, it's a modules vs. non-modules difference... and the only reason it is tied with modules is because we were thinking we wanted to make a backwards-incompatible change here, and it's nice to group all backwards-incompatible API changes together.

specifically the idea was to move

cf

somewhere else, like onto the new "context" object.

which might help as we add new event types other than

fetch

, like

scheduled

buuuuut... it changes the model of what

request.cf

is, especially in the case of a multi-worker pipeline.

does the first worker in the pipeline get to change

request.cf

before sending it on to the next worker?

currently, it can. On the context object, I suppose it wouldn't be able to.

in that case all workers in the pipeline would presumably receive the original

cf

. But is that... right? What if one worker in the pipeline wants to hide some information from later workers? It's hard to think about this when the use cases aren't clear yet.

For

scheduled

, it's clear - I noticed that the context arg is already being passed as the 3rd arg, and the incoming cf props would be unambiguous there. By multi-worker pipeline, do you mean workers calling DOs via fetch? or workers calling other workers? (across zones). For the latter, shouldn't

cf

always be clear (should refer to the one being called)? So we're really talking about DO fetches. In that case, the same "caller info" referring the calling request is the most unambiguous, any n-level call stack should be probably left to the app via a correlation id etc.

multi-worker pipelines arise today with Cloudflare Apps, when the app has a worker... the app's worker runs first, then the zone's worker. In the future we expect to use pipelines for more things.

like being able to have your own workers call each other directly without going through a URL

Ah interesting, imo a readonly

cf

for the incoming request makes the mental model easier, even when multiple workers are in play. Not sure what the value of a Laplace's demon worker changing the colo / location info for downstream workers is, but maybe you have some crazy internal worker scenarios : )

the thing is,

cf

is used for all kinds of things. It's really just "additional headers that won't get transmitted outside Cloudflare". So rewriting it is like rewriting headers, and obviously rewriting headers is useful for all sorts of stuff...

moreover

cf

contains a lot of info about the original request received by our edge, but passing such information down through several layers of workers might be breaking layers of abstraction

Maybe it makes sense to distinguish read-only cf props in a formal way, like in a new property, but I'm really struggling to think of why allowing modification of the [IncomingRequestCfProperties](https://developers.cloudflare.com/workers/runtime-apis/request#incomingrequestcfproperties) would do anything but cause confusion.

how do you use waitUntil inside a cloudflare DO?

constructor?

constructor(controller, env, ctx) {

setTimeout does not work inside a DO?