(the “via” item in the latency display is the worker colo)

Ahh, alright - that's quite slow then, as I get 26 ms latency when running a Speedtest on the VPN. Cloudflare does peer with M247 in Amsterdam, right?

Hmm, pinging

1.1.1.1

(on VPN to M247 in Amsterdam) gives me a latency of 28 ms, so perhaps the route between AMS and FRA is just slow for some reason?

Is it possible to move an web-socket connection from the worker to a durable object?

yes, you pass the websocket request (with the "Upgrade: websocket" header) to the DO via

stub.fetch(request)

When I have durable object, let's call it xyz I must use fetch to communicate with it? or could I call it's functions directly? example: xyz.storage.get('key');

Yes, fetch only

ok, thanks

seeing these today "Error: Internal error in Durable Object storage write caused object to be reset."

It looks like we have some sort of bug where some errors like this happen while we roll out an update to the workers runtime. We are looking into it. (FWIW, whenever you see "internal error" that means we think it's our bug, not yours, and the error has already been reported to our internal monitoring.)

I need to use an NPM package in my Durable Object project - can someone tell me which of these templates would allow me to do that? Thanks! 🙂 https://github.com/cloudflare/durable-objects-template https://github.com/cloudflare/durable-objects-rollup-esm https://github.com/cloudflare/durable-objects-webpack-commonjs

https://github.com/cloudflare/durable-objects-rollup-esm is (IMO) a good place to start -

It even shows importing a package in the example entrypoint: https://github.com/cloudflare/durable-objects-rollup-esm/blob/master/src/index.mjs

Alright. Thanks!

(I use Rollup on my own projects, and ES Modules are the way forward, especially with Durable Objects / Workers’ Modules API)

Is it possible to know where in the world the durable object is?

one way is to fetch

https://1.1.1.1/cdn-cgi/trace

from inside the DO, and cache the colo field from that trace

iirc module workers are now passed a

cf

property on each incoming fetch request, so

request.cf.colo

is defined for the incoming worker request, but the

Request

passed to your DO's

fetch

still does not have the

cf

property (I just double-checked) - it makes sense since many of the custom

cf

properties don't apply for the internal DO fetch calls, but a colo accessor (maybe on

state

?) would certainly be useful

Yeah having the CF property specific for the worker would be great!

in case you haven't seen it, check out https://where.durableobjects.live/ by @jed, a cool idea to find out which cf colos support DOs at the moment

🤔

hehe, probably a colo he doesn

t have his master list yet

It's on VPN to Albania - thought I'd populate the list some more 😛

it would be so nice to be able to send a worker request to a specific colo for testing this sort of thing

correct colo this time

wait,

colo=PRG

maybe pager went off : )