I wonder if

list

and

put(entries)

also take similar optional bypass args...

ping on this issue, any way possible to get a reply?

lol just came here to post that, you beat me

Yes, all the storage ops accept bypass flags. (For

list()

, they go into the existing options object. For others, it's a new parameter.)

(now that the post is out, I need to update the docs...)

Hey @User , do you see the same problem in a regular stateless worker (not a Durable Object)? Could you write a minimal self-contained worker that reproduces the problem which we could debug?

actually this should be a thread

Two questions: 1) It wasn't clear to me whether it's now better to "await" a .put() operation or rely on automatic await before the final response. 2) What's the behavior of ctx.waitUntil(()=> storage.put()) ?

Hey @User, are there any plans for a DESTROY function or something similar, that would allow you to terminate a DO instance and wipe its data(

OBJECT_NAMESPACE.get(id).destroy()

)? Or a way to remotely force a reset of the DO from

wrangler

, without having to delete and recreate the instance?

If an object deletes all its storage (e.g. with

storage.deleteAll()

), then it will cease to exist once it shuts down.

How'd I miss that?

heh, it's definitely an unusual model and not obvious

but "implicit create, implicit delete" turns out to work really well because it means the clients don't have to check if an object exists or try to synchronize deletions... they just send messages to the object

Is there a plan for the ability to wipe them from

wrangler

too? I sometimes make some changes to my code that might leave fragments in storage, so I want to start from scratch, without manually having to built that logic into the DO code.

If I run

deleteAll()

on a

idFromName()

-object, can it migrate to a new PoP if created again?

AFAIK, the

deleteAll()

function only works on

this.state.storage

inside the Durable Object, not in the Worker itself.

You can delete the whole namespace and recreate it from wrangler. We plan later to add the ability to list existing objects and perhaps to schedule a function to run on all objects.

I actually meant running the function inside an object created using

idFromName()

- my fault.

Yeah, it can recreate itself at another time, but without the previous storage.

also at another PoP?

Is that

wrangler publish --delete-class MyClass

, and

wrangler publish --new-class MyClass

?

Yeah, the recreation should then be by the nearest POP that is a valid DO hosting colo.

right

at present it's likely to stay at the same pop. To move to a new pop, you'd have to wait until all cached traces of the old object have been wiped from the system, which could take a while. But we're still working on automatic migration.

(though if you deleted the entire namespace and created a new one, then nothing carries over)

Alright, that makes sense!

@User How the in/out gates plays with the ctx.waitUntil? Will this break the rules?

ctx.waitUntil()

doesn't actually do anything in particular anymore. The object keeps running for at least 30 seconds after the last request whether or not use use waitUntil().

But if we use storage operations on the waitUntil, we will be able to make a response without actually wait.

Ah. Yes, deferring code to run after the response has already been returned is inherently unreliable, because in the case of a failure, no one finds out. E.g. if the power goes out, the task might never execute, but since the user already received a response, they won't know. Output gates can't help with this, since they can't predict what you're going to do in the future after you return the response. Generally, I don't recommend doing this, except maybe for stuff that is fine to be unreliable, like logging.