specifically because the alarm handler calls deleteAll()

otherwise the things stored with storage.put would remain in durable storage indefinitely, even if the DO was not running

seems odd not having a way to explicitly delete an object, will need to make sure to write code that clears out the contents after its done being used and then prevent future requests to that id

if you had a way to explicitly delete an object, besides deleteAll, what would you expect to happen with concurrent or subsequent requests to that object?

I couldnt find an answer in the docs. Can I call a service binding from inside a durable object?

Yea

https://developers.cloudflare.com/workers/runtime-apis/service-bindings/#context > Service bindings live on the environment context. This means Service bindings can be used from within a Durable Object, as long as the environment context remains intact. There it was

Is there somewhere that mentions how accurate alarms are?

I think I read somewhere that they're checked every 30 seconds, so they could be withing 0-30s of the scheduled time?

Alarms can be set to millisecond granularity and will usually execute within a few milliseconds after the set time, but can be delayed by up to a minute due to maintenance or failures while failover takes place.

What happens when I exceed the RAM limit on a worker or durable object? Will it spin up another one and just cost more or is there anything I have to do?

It will throw an error on the fetch call

Thank you!

Thanks, that's pretty snappy!

Are there any videos that cover the same kind of material as this? https://blog.cloudflare.com/durable-objects-easy-fast-correct-choose-three/

Or any other good resources for getting to grips with the concept of the gates and the guarantees they give you

And how it compares to a traditional database transaction

I'd expect failure, because it was explicitly deleted. The docs even mention that it's possible for deleteAll to fail so you'd need to build code around that as well to make sure it's cleared out. I'm thinking I might even need a kv entry for each one that I can check on every call to see if I'm done using it so I don't inadvertently keep it alive with future calls to the id. Previously I was going to use the id generated with newUniqueId in the URL.

so you're expecting deletion to permanently remove an ID from being usable?

Yeah.. I can see how that might be a problem for id's created by name, doesn't seem so for what's mentioned on newUniqueId, but I expect they wouldn't want the behavior to change solely based on that.

I suppose if I write what I need to make sure deleteAll succeeds eventually then the problem isn't mine after that if they aren't limiting the number of objects and an empty object doesn't consume storage.

Error: Cannot resolve Durable Object due to transient issue on remote node.

this has happened a couple times for us in production. anything we can do?

generally for transient errors backing off and retrying is safe

I'm seeing a lot of these transient issues too. >

generally for transient errors backing off and retrying is safe

Would the platform ever give us an option to let this be handled by Cloudflare rather than writing user code to do this? I thought the entire point of moving my workloads to Cloudflare is to not worry about these issues.

Oh hey, been meaning to ask. Given a set of DO stubs, is there a way to route to the nearest one?

can you quantify a lot? timeframe? DM me specific object IDs if you have them

I am iterating over thousands of objects, sorting them into tens of DO instances. If I call

idFromName

, get the stub, and then call fetch on that once for each object in a loop all in a single worker, should i be caching the stubs? Or will the

idFromName

and

env.DO.get

operations be sufficiently cached automagically by cloudflare that it shouldn't really matter?

Its unclear what the overhead of calling

idFromName

with the same name, or getting a stub from an ID is if the same name and id are used several times in a row

idFromName should be safe to cache, but I also wouldn't expect it to save you much in terms of efficiency. If you want to reuse stubs, just be aware you'll need to recreate them on error, there's a note in the docs about this at https://developers.cloudflare.com/workers/runtime-apis/durable-objects/#object-stubs

hopefully somebody smarter than me can implement it here... https://github.com/kwhitley/itty-durable/issues/33