I'm on the Workers Paid plan but my zone is on the free plan. Does this mean I don't get the preferable worker locations, or is the routing also affected by the worker plan?

Routing is affected by your zone plan, which is separate from the workers plan, yes.

You had the classes still bound in the wrangler settings. I ran into this and simply renamed the classes in the code, removed the binding settings then --delete-class to remove the old. Then update the wrangler bindings to the new class name and --create-class. I thought about even starting to name DO classes with unique strings in the future to make it easier.

I had similar situation with delete. --rename-class Oldname NewName worked nicely

so, our current use case: (numbers may vary) 3-5 minute PvP teal time "strategy" sessions between two players "strategy" under quotes since units tend to be defined by like, 5 factors each and have pretty simple behaviour while our client is 3d, everything logic-related can be done in 2d, which was always our backend solution players can have a maximum of 8 units each, but it very rarely happens (never seen in in 6 months as a junior) that all of them are on the map at the same time the loop would need to iterate over those units, check their states, occasionally proc some minor logic (target and path finding) on them, and depending on our network architecture (still brainstorming concepts on that one) maybe send some data to the clients

The error comes from leaving the durable object binding configuration for that class in your wrangler.toml. We’re working on better error messages for this situation

Hello! Can DurableObject keys have a expiration like the KV store?

Not yet. Note, though, that if you don't store anything to disk, then the object ceases to exist at all once it shuts down. So for objects that only have in-memory state, there's no need for an expiration. For objects that do store some stuff to disk, we're working on a solution.

Ok, that's perfect. Can we control the lifetime?

What do you mean?

If it is shutdown 5 seconds after processing it may not be as useful as it shutting down a minute after processing.

It'll be at least 30 seconds under normal conditions (no unexpected machine failures, etc.). There's no way to control that yet.

ok, thank you!

How does the “script has been updated” error fit into this? Trying to wrap my head around graceful upgrades. Currently I store every single time state is changed, which is too expensive for production use. If I had an event “eviction imminent, do what you must, right now” then I could batch my writes on a timer. In addition to that I would need a way to terminate this instance, meaning all future connections would go to a fresh instance.

The eviction event would also be useful for me

The struggle we have with providing an eviction event is that there will always be cases where we aren't able to deliver the event ahead of time. For example, the power could go out. Ideally, applications are prepared for failures to happen at any moment, so that they are resilient against such issues.

That's something every application needs to cope with, but it would be great to leave the developer weighting risk/benefit in that case

Sometimes it'd be useful to batch writes every 15s for instance, and once on script shutdown

So the damage of a power outage would be limited

I guess one could start a 15s timer after the last connection to the DO has been terminated and write then, but the event would be a lot sleeker

I get that. Let me rephrase. What is a good way to handle the “this script has been updated” error, given that the DO accepted a new connection even after that error?

Hmmm what do you mean by "given that the DO accepted a new connection even after that error?"? This is sounding like it might be a bug? Any new requests should go to the upgraded version of the DO...

https://discord.com/channels/595317990191398933/773219443911819284/848683165647372349 (see this log and my explanation)

Ahhhh, so this is a split-brain problem, the old version of the DO is still running (despite the client having observed an error), and a new version starts, but the old version is still able to write to storage in the meantime? I believe we have a fix for this problem going out next week, although the fix simply ensures the old version can't write to storage anymore.

Okay, that's what I'm doing now, manually (close all websockets, delete my storage accessor)

... by pattern matching any of the fatal errors

("send a new request", "exceeded the number of timeouts")

yeahhhhh we should probably find a better way to signal error types.

... although the timeout error might reconnect to the same DO 😦

which is why I was asking for a way to shut down this instance and start fresh