yes also

[env.staging.durable_objects]

based on your wrangler.toml

thanks that did the trick 🙌

Thanks @User!

FWIW: wrangler tail is wonderful working here again and now I can get the logs from the DO itself (is listed as fake-server , nice )!! Thanks so much for this!!

Question: If a deploy a DO using WASM the entire bundle should be 1MB right? Theres any support to load wasm modules from KV?

1. Yes, as far as I know 2. No, we can't allow loading external code at runtime for security reasons

any ideas regarding this error when using the new modular syntax in lieu of supporting durable objects?

I have a DO with a lot of keys that i'd like to delete... what might be reasons why storage.deleteAll() isn't deleting every key? the docs mention

In the event of a failure while the deleteAll() operation is still in flight, it may be that only a subset of the data is properly deleted.

but I'm not sure what might cause that and I don't think I'm getting an error back

edit: I think it deleted them all. seems like I had to call that function a few times? does it have a cap?

@User How many keys did it have?

I have no idea, i was accidentally adding new keys in a loop for a while. so a bunch

2 questions: 1. whats the expected probability that a DO will be evicted? is it based on application memory or global demand? 2. do DO's provide a handler for eviction?

Hm. It doesn't have a cap, but it can take some time to delete all of your keys if you have a ton. While it's running you should be prevented from doing other storage operations in that object, so if you were able to get/list to check on your keys "during" the delete then it seems like the previous deleteAll must have stopped (presumably with an error?) for some reason... are you workers setup in such a way that you would have caught and sent that error to yourself somewhere?

1. We don't currently evict DOs that are actively in use, but the machine/process they are in could always crash. We also plan to migrate DOs soon, so you have to be prepared for transient state to vanish (for multiple reasons). 2. No handler currently. Even if we had one you couldn't depend on it because of the crashes noted above. If you're worried about data loss from eviction/crash you should follow the model in Counter example in docs, where we persist data and (re-)load it up into transient state in the constructor.

Thanks!

Weird that the documentation says you can have unlimited storage per object

If you are limited to 128 key values pairs and each value is limited to 32kb

Seems like a hard limit to me?

Where do you see a limit of 128 KV pairs?

I swear I saw that somewhere

Is that not correct?

“Supports up to 128 of pairs at a time”

That's for get()

That's the documentation for `get`/`put`

Ah

Google being google

My bad I should have probably followed the link