We had a burst of networking problems from 5:02-8:25 UTC in APAC that caused Durable Objects in the region to be unreachable

That's very unfortunate

Just to check, durable objects are only available with the paid plan here, right?

yep

your link is private to people who have access to your worker but yes, the DO beta is tied to paid plan

cool, cheers 🙂

hi. i'm trying to publish a DO but i get this error: Error: Something went wrong! Status: 400 Bad Request, Details { "result": null, "success": false, "errors": [ { "code": 10074, "message": "Cannot apply new-class migration to class ThreeCommasState that is already depended on by existing Durable Objects" } ], "messages": [] } i tried to delete it and get this error: Error: Something went wrong! Status: 400 Bad Request, Details { "result": null, "success": false, "errors": [ { "code": 10074, "message": "Cannot apply new-class migration to class ThreeCommasState that is already depended on by existing Durable Objects" } ], "messages": [] } i tried to delete the worker and got an error: "script still in use by a durable object namespace (Code: 10064) and i saw someone suggested i use curl to delete through the api and i get: {"success":false,"errors":[{"code":9106,"message":"Missing X-Auth-Key, X-Auth-Email or Authorization headers"}]}

please can someone help me?

Sounds like when you publish you are running

wrangler publish --new-class ClassName

when all you need to do is

wrangler publish

because you have already uploaded the durable object class itself. To delete a class you would do

wrangler publish --delete-class ClassName

then you can delete the worker.

@User ^^

before i adjusted my project to follow the DO template setup, when using wrangler dev, i could make changes and save and it would detect the changes and the new code would be running almost immediately. now when i save, it does the whole build process over again each time (i have my ide set to recompile on save). i'm assuming it's because of the new custom build stuff in the wrangler.toml file. is there anyway to have the previous wrangler dev behaviour or am i stuck with this now?

AFAIK it always did a full rebuild, but it is probably that the custom build takes way longer than the previous one.

Yeah ive never had it not full rebuild so not entirely sure how to help haha

So me and my team have been having a little trouble with the DO setup - We're having issues with importing jsonwebtoken (https://www.npmjs.com/package/jsonwebtoken>) (commonjs). We forked https://github.com/cloudflare/modules-rollup-esm here at https://github.com/interfacers/modules-rollup-esm/tree/bug/json-web-token-buffer-issue where you can reproduce the problem. Any ideas of how to resolve this issue?

A lot of libraries on npm assume that you are running it in NodeJS, which has a bunch of extra modules. Workers run on a straight V8, and the extra modules are mostly based on browser versions.

@lukeed, do you know of a JWT token parser that works on Workers? Or should I make that my next Quick Win project?

@User so we had no problem using jsonwebtoken prior to using the modules format.

Really? Importing buffer was never going to work. And it should be easier, not harder to treeshake? Are the versions different by any chance?

hi evan! jsonwebtoken version is the same, only change is from webpack to rollup and cjs to esm

I have got nothing then.. can you strip out everything but the most basic of worker with jsonwebtoken with your build setup and put that in a repo I could have a look at?

sure. we did this already, see above link https://github.com/interfacers/modules-rollup-esm/tree/bug/json-web-token-buffer-issue

this just reproduces the problem, we stripped out the durable objects and the rest of our code

Ahh, I misunderstood that. That is super weird. I am going to try to have a look at (my) night, but it is 9pm here and I have some stuff to wrap up. Will try to have a look at it. Maybe Luke can have a peek at it when he wakes up.

great, thanks a lot! no rush, we're happy to receive some feedback at all since it's not so clear to us if this is a cloudflare or a rollup issue - using jsonwebtoken with the default webpack setup just worked

Yeah, I have no idea either from skimming your code.

we're already glad we could trace the problem to this import and can exclude it's DO related. it's not so clear however what the limitations of CF workers are - you said buffer should not work - is there documentation on the limits of the current node support of CF workers?

There is currently no node support at all.

These are all the runtime APIs available. You can easily alias in a JavaScript version of the simpler NodeJS modules like path, but http for example is just not possible.

i see. maybe then buffer was not required for the functions we used in the worker, maybe it could be stubbed out or polyfilled with https://github.com/feross/buffer to fix the build