suspicious that it started almost immediately after midnight utc - let's see if that turns out to be a factor

Okay folks, we're officially to monitoring: https://www.cloudflarestatus.com/incidents/gx3897cpcrm7

seems it is indeed fixed 🙂

yes seems back to normal, lasted about 2 hours

Any answers on this?

You can achieve that using alarms

Certainly, one could do it in many ways, but where's the elegance in that vs the inbuilt mechanism.

DO storage is completely unrelated to KV storage, and there are no short term plans to add TTL to DO

you could use

do-taskmanager

to automatically create TTL alarms, it makes them pretty convenient, I think around 5 lines in total?

Struggling to find this library, do you have a link?

I see it uses a separate DO as the task manager. Is there any reason it would be a bad idea to just have the alarms managed from the DO itself?

Thanks @kian for the link 🙏 The library uses the same DO, just wraps it with a withTaskmanager call and uses proxy to take over set/getAlarm methods - so you don’t accidentally mess up task management with a regular alarm

Ah thanks! I clearly didn't read the readme very carefully "TaskManager uses the same durable storage that your durable object uses, with the $$_tasks prefix"

if you are using itty-durable you can use my gist which combines itty-durable and do-taskmanager (well sort of!) https://gist.github.com/aarhus/d7d6d7e1778367994f9e33c37a08074e (edit to add link to gist)

I have a question, when we change data in-memory, we need to save it ASAP in storage, to prevent the case of DO eviction/kill. So, this also mean we should not do the memory change (or revert it back) in case of storage failure, to prevent any instable behavior. I have the option to create a clone of our data, modify this clone, save in storage this clone and only if there is no storage failure, to replace the original with the clone, but it's cost a lot in memory (we have list of million of products...) Another option, should be if the storage fail, to have a kind of state.reboot() function, then it's restore the previous saved state in memory, and prevent to do some clone of everything the save in memory. Is CF have some suggestion for this case ( even if I suppose it's really rare )

If you're worried about inconsistent mutations being observable from the outside, you can use a pattern like

do-transactional-outbox

does - https://github.com/evanderkoogh/do-transactional-outbox

I don't think there is a way to "reset" state in a DO, other than throwing an uncaught error and retrying from the outside 🙃

and if you 100% need state to be stored, I don't recommend "hoping for" the DO to stay alive for 20-25s before storing it to persistent storage

Thank @Dani Foldi for your suggestions! May be I should mark in-memory the DO as « instable », and return an error to permit to retry from outside. Then, if the person retry in the same window of ~30s, the in-memory "instable" value prevent to do anything, but after eviction of the DO, everything should be back from the storage in a normal state. What do you think about this idea?

hmmm, yeah it's close to what we have - we created a member on the DO class to act as a cache - we created functions that wrap state.storage.get/set/list/delete - on get, we first check if the cache contains the key - on set, we write to storage, then to the cache - potentially remove some elements [LRU] from the cache to keep memory usage down If at any time the DO gets restarted, we get "cold" reads for a while, but for frequently accessed values this works nicely

If a storage op fails the DO resets already

doesn't that just throw an error? 🤔

or is it just that we catch such issues in the eyeball worker and retry anyways

I'm playing around with a wrapper that takes care of this. Look at these 25 or so lines. The idea is to take your current durable object Class and wrap it with this one. This one will instantiate yours and control the eviction of it from memory when either an error is thrown or you return an error code >= 400. This causes your DO to rehydrate from storage on the next call. It uses DO's explicit transaction functionality. With this your memory always stays in sync with storage and it also assures that your storage is self-consistent across multiple keys. https://github.com/transformation-dev/blueprint/blob/b7e15e235ab9b285a68f7b8f444c6f9270c8ad2d/packages/cloudflare-do-utils/src/transactional-do-wrapper.js#L84...L109

Here's my first draft of the docs for it: https://github.com/transformation-dev/blueprint/tree/cloudflare-do-utils-2/packages/cloudflare-do-utils#transactionaldowrapperbase

Very interesting ! I've just read your docs, I'll try it, thank you

I red the docs but still don't understand where I should place the code of the durable object. I see in the docs that a class needs to be defined and all other things but not clear what folder it should placed into relative to the worker. same folder? same file that defines the worker? any other random place in the file structure not related to the worker whatsoever? can someone please show some basic example? I saw the chat example one but it is quite advanced and complex. yeah I am beginning software developer and therefore even simple demos look to me hard. hopefully in a month or two I will get used to it

The Worker itself should export the Durable Object class. So wherever you do

export default { };

, you should also do

export MyDOClass

. The class doesn’t have to be defined there, but it has to be exported there

this is what chatgpt suggested, do you think it is a good suggestion?