Is it possible to move an web-socket connection from the worker to a durable object?
Is it possible to move an web-socket connection from the worker to a durable object?
Cyes, you pass the websocket request (with the "Upgrade: websocket" header) to the DO via
KWhen 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');
or could I call it's functions directly?
example: xyz.storage.get('key');
CYes, fetch only
Kok, thanks
KIt 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.)
AI 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-template
https://github.com/cloudflare/durable-objects-rollup-esm
https://github.com/cloudflare/durable-objects-webpack-commonjs
MGitHub
Template for durable objects, rollup, es modules. Contribute to cloudflare/durable-objects-rollup-esm development by creating an account on GitHub.
MIt even shows importing a package in the example entrypoint: https://github.com/cloudflare/durable-objects-rollup-esm/blob/master/src/index.mjs
GitHub
Template for durable objects, rollup, es modules. Contribute to cloudflare/durable-objects-rollup-esm development by creating an account on GitHub.
AAlright. Thanks!
M(I use Rollup on my own projects, and ES Modules are the way forward, especially with Durable Objects / Workers’ Modules API)
IIs it possible to know where in the world the durable object is?
Jone way is to fetch from inside the DO, and cache the colo field from that trace
Jiirc module workers are now passed a property on each incoming fetch request, so is defined for the incoming worker request, but the passed to your DO's
fetchYeah having the CF property specific for the worker would be great!
Jin case you haven't seen it, check out https://where.durableobjects.live/ by @jedschmidt, a cool idea to find out which cf colos support DOs at the moment
AJhehe, probably a colo he doesn
Jt have his master list yet
AIt's on VPN to Albania - thought I'd populate the list some more 
Jit would be so nice to be able to send a worker request to a specific colo for testing this sort of thing
AAcorrect colo this time
Await,
Jmaybe pager went off : )
Aseems to change a lot from this location
AA- it was 44% when I started
Jdenominator+++++++
AAlright, I "managed" to bring the percentage down to 37. Won't spend anymore time on this 
JJ(tho should’ve handled that more gracefully)
HHow'd I not noticed that? I needed the locations of the datacenters for a project, so I scraped them off the statuspage then geocoded them.
CGuess I should update my latency map durable-objects
Ji did the same until i found that endpoint!
Jgood thing workers makes scraping so easy…
CActually no - the coords in that list are literally the airport coords which makes the map look rather weird zoomed in. I'll keep my reverse geocoder.
HDoes your Latency Map test latency to your datacenters, or the actual Colos?
Cit's measuring roundtrip latency client – worker – DO – worker – client using a websocket connection (as we do for our "real" apps)
HAnd how do you figure out which colo the DO is in?
HShould have foreseen that.
C
CHmm, curious. One of my DOs moved from LAX to SJC today 
Is that supposed to happen?
Is that supposed to happen?HMight have been me...
HSorry about that, @codefrau!
CHuh? How? Supposedly DOs are fixed to one colo, unless that colo is down, I thought
HI believe that DOs persist in one colo, until they are shut down. Once they are triggered again, they are reinitialized in the nearest DO-ready colo to the incoming request.