Yeah, in JS

fetch(url, {method: "POST", body: "foo"})

definitely works

When you say it won't pickup the request you mean you don't even see the DO receiving a request? Are you sure it doesn't throw an error in the DO for an unrelated reason?

Yep, I send POST requests with bodies (from JS) in almost every DO call

Glad to know it! I'll try to figure out what's different from our library then.

what does it mean for a request to get "canceled" ?

Aborted by the user possibly? Like hitting the "X" button while loading? Or via an

AbortController

with

fetch

or something I'd imagine?

Is it just a regular HTTP request? I get this quite often with WebSockets but assumed it happens because of garbage collection after X seconds / minutes of no more incoming requests in the DO

It's a web socket upgrade request

It seems to happen immediately though

Usually that means the client disconnected. I think in the case of WebSockets it might include when the client disconnects long after the WebSocket is established and a healthy conversation has taken place.

for a normal HTTP request, it means the client disconnected before the response was sent.

I found the bug @User . CloudFlare Workers' implementation of WebSocket doesn't support the

readyState

property. It is undefined. Similarly the constants

WebSocket.{CONNECTED, CONNECTING, etc}

are undefined. This was causing our code to close the connection early. We did not notice this because the typescript type we are using (from https://github.com/cloudflare/workers-types/issues/84#issuecomment-813114157) uses

interface WebSocket

which adds the method

accept()

to the built-in

DOM WebSocket

type. The DOM type does have

readyState

so typescript didn't complain, it just failed at runtime. If CF can't completely implement the spec, it would be helpful to publish and maintain your own types, as otherwise this kind of thing is very confusing to debug.

Sorry about that. At present, in Workers,

readyState

is not that useful because by the time you obtain a

WebSocket

using our APIs, it's always already in the

OPEN

state. But we should fill out the API with all the standard methods and properties nevertheless.

👍 another question - will

worker.send()

ever throw between

accept()

and

onclose

? I remove the worker from the active set in

onclose

but i'm worried about it transitioning to a closed state or some other not-ready state without that event firing. That's why I was checking the

readyState

property before calling

send()

.

as currently implemented, it appears that send() may throw: * if

accept()

hasn't been called * if

close()

has already been called * if

onerror

has fired. Otherwise, it adds the message to a send queue, which shouldn't ever throw. (I say "shouldn't" because saying "it will never throw" is like saying "there are no bugs".)

makes sense, thanks.

I'm not sure if I actually intended to make this guarantee but it seems to be the case and I suppose if it's the case now we can't undo it later.

note that

send()

doesn't care if

onclose

has occurred since they represent opposite directions of the stream.

onerror

is what matters.

ah, right. thanks!

working on something pretty cool with replicache+durable objects.

nice, looking forward to seeing it!

Hey @kenton, is there a feature on the roadmap to support spawning a DO in a specific colo/region/continent?

Hi @User @User , any updates about our case? We are unable to deploy for more than a week. It probably affects more clients (It affects any "modules" project with at least 1 file inside any nested directory)

You can already bound to EU but more specific would be a great addition!

Can you describe your use case? Currently we support specifying jurisdictions (EU to start, more coming) but that's meant to be for compliance purposes. Is that what you want, or do you have another reason for wanting to choose the location of a DO?

Yikes, that hasn't been fixed yet? I'll poke some people.

Definitely not a large need for this, but I had an idea for a small file-sharing service, that would allow you to input the general location of the person you are sending the file to, then it would upload the file to the nearest colo to you, transfer the file to a colo near the receiver, then wait for them to download it.

I see, interesting. Generally we're trying to avoid making developers think about regions, so we want to look for ways that we can make it automatic. Here, if the receiving user had an account already, then it could be that a DO is created associated with that account and is thus in the right location... but if the receiving user doesn't have an account in advance and the sending user is really just specifying explicitly where they are then I guess there's no way to make that automatic, hmm.

Ooh, interesting idea. Maybe two separate clients could share a connection code, which would then generate the instances automatically in the nearest colo?

It's impossible to predict all user cases that anyone may need to proactive store any information in advance in some place. Automatic migration is nice, but its also nice to choose (for some strange reason or not) our colo(or region) if possible.