yea perhaps some logging and sometimes https://developers.cloudflare.com/workers/platform/logpush/ can help debug weird termination errors

does it help log any errors when the termination happens?

depends on what it is - sometimes it is better than nothing (will provide a clue), sometimes not. it will always trace something at termination though, which is sometimes enough info in itself and more than can be said for regular logging inside the DO code

oh that is good to know

oh yeah I already setup log push. turns out I have 2gb of logs

lol

https://castbox.fm/episode/Termie-doesn't-save-logs-id5412624-id590018936?country=us

Can someone lemme know on this, never received an answer https://discord.com/channels/595317990191398933/1075775029700198440/1079037639090520084

Sharing of global memory is on a script basis, docs were updated to reflect that https://developers.cloudflare.com/workers/learning/using-durable-objects/#in-memory-state-in-a-durable-object

No I'm not talking about global memory. I'm talking about this hidden restriction mentioned under pricing https://developers.cloudflare.com/workers/platform/pricing/#durable-objects "If your account creates many instances of a single Durable Object class, Durable Objects may run in the same isolate on the same physical machine and share the 128 MB of memory." So to repeat my question: If I deploy the same worker + DO code (mjs) under different names and paths, will the DO be shared, and thus fall into the definition of "many instances of a single Durable Object class"? Or is (worker x DO class) unique? And as a further query, if the same named DO class is used in **different **Workers, will it also fall prey to this restriction?

Same thing - the reason global memory is shared is because the same physical machine + isolate is shared, and the boundary for that is the script

Depending on what you're actually trying to avoid, using a different script may or may not help. Instances of the same DO class name defined in different scripts won't share memory across those scripts, but instances of each of those classes may share memory with instances of the same script.

Thank you @ckoeninger. I'm just trying to understand the boundaries/restrictions so I'm not caught unaware at a later point in production with scale. So, as you mentioned above, sharing is always at the script level. TL;DR: 1. Instances of DO classes may share memory with instances of the same script 2. Instances of the same DO class name defined in different scripts WONT share memory across those scripts

I forgot, isn’t there a persistent ID for a DO class separate from the name? How do you identify which class is which, if both are named DurableClass?

Durable objects have a namespace ID

Not really. If two classes both export DurableClass, how do I know which one is which, without just knowing the script that exports them?

there is a persistent id for a DO namespace but it's not really exposed anymore, classname combined with scriptname is a sufficiently unique identifier and that's how bindings are specified

It is exposed in the GQL api 😛

And on the dash actually never noticed it

sorry I mean the process for creating / interacting with a durable object namespace that way isn't really exposed anymore unlike beta, if you're configuring stuff about a DO you're not doing it on a namespace id basis the way you would with KV

Yeah true

It’s really odd lol. Scripts expose a class name, classes have a unique ID, but if you try to select them on Pages for example, you don’t select by class or script, you select by a class-script concat

It is easier to know what the object is by the class name and script name, not sure why you would want to select by the namespace ID. The class name and script name have to be unique anyways

Yeah, I was just commenting on the fact that you can’t select by script, and then by class. So if you have a lot of classes, it might be a bit more difficult to find the one you are looking for

Hey y'all, are you using some kind of type-safe router/client when talking to your durable objects? I'm looking for something that feels like I'm calling a fully typed function instead of fetching directly. I get that the Cloudflare team just wants to worry about supporting JS, but I've moved on from it and the weak fetch types are not good enough of a development experience for me.

speaking of itty-durable... I patched it to allow for auto retrying: but, we still get errors like this in production:

cannot access storage because object has moved to a different machine

I thought that with my patch these sorts of intermittent errors would basically get eliminated in Sentry there is no stack trace available at all for some reason when these sorts of DO-related errors happen any ideas? it has been bothering me for a while lol

Looks like you arent recreating the object stub which I believe would mean it doesnt go to the new object because the stub you are using still refers to the old object.