thought so but thanks for confirming 😭👍

Is

blockConcurrencyWhile

used internally? I'm seeing new

Error: A call to blockConcurrencyWhile() in a Durable Object waited for too long. The call was canceled and the Durable Object was reset.

errors but I don't have any calls to

blockConcurrencyWhile

in the script

are you using transactions?

To elaborate on @ckoeninger's question:

storage.txn()

is actually implemented in terms of

blockConcurrencyWhile()

, so if you are using that, that could explain it.

Do the implicit transactions also use blockConcurrencyWhile()? 🤔

I had the same question, from reading the documentation I got the impression that explicit and implicit are kind of the same under the hood.

aha good to know, yes i am using storage txn, but only for storage ops - i guess one of those hung for a bit and caused the entire object to be reset?

I have a few errors where blockConcurrencyWhile throws that message also when all I do is a get on initialize in the constructor which does seem odd for it to error on a storage op when it just started up 😛

This error is a fun one just "internal error" lol

Managed to also catch 1 DO apparently moving machines

Hello, I have an application where I would like to use a Durable Object's clocks in a limited manner. A clock that can tell me the time that the http request/websocket message was received would be sufficient for my needs. However, I am observing Durable Object's clocks lose time across request, eventually getting multiple seconds behind. The rate at which time is lost appears proportional to the amount of computation done by the DO. I do not see Worker's clocks lose time in the same way. I'm aware that clocks on the Worker platform have been limited in ways to prevent Side-channel attacks (https://developers.cloudflare.com/workers/learning/security-model/#step-1-disallow-timers-and-multi-threading). I know they cannot be used to measure execution time of code because they are frozen to the time of last I/O (https://developers.cloudflare.com/workers/runtime-apis/web-standards/#javascript-standards). However, I am seeing time lost across request (i.e. across I/O events). Is this expected? I have created a small test set up to demonstrate the issue I'm observing. The code for it is here: https://github.com/rocicorp/cf-worker-clocks and it is running here: https://cf-worker-clocks-test.replicache.workers.dev/

So, trying to wrap my head around DOs and its usage. If I have a constraint that a key is going to be >512 and <2048 bytes, could I technically use DOs as a KV store only or is this an incorrect usage for this? I understand there are limitations in read RPS, 50GB global limit etc and persistence can possible using the transactional storage API. Would I be running into any issues if I use it purely as a KV store to get around the 512 byte key limit .

Some incredibly niche feedback to the Cloudflare dev team, for me (and probably the other 5 developers) using pure functional compile-to-JS languages on your platform: it's not always very clear how my asynchronous code is going to look when it's compiled to JS, having explicit transactions be a first class feature is very helpful, I've got a pretty large Worker/DO/R2 library I'd like to open source at some point, and it does rely on txn.

DOs cannot store values as large as KV. Limit of 128KiB per value vs 25MiB. DOs are also not replicated like KV is (KV has 2 central stores, one US one EU). And of course there are different throughput limits KV has unlimited throughput (other than write 1 per second to the same key). DOs limits as an exclusive key value store should be pretty high for both write and read (you can extend read far beyond write if you use the cache api as well). With DOs I would also make sure you are using multiple object ids to spread your keyspace across many objects increasing the overall throughput.

Curious, does anyone have any information about how durable objects handles network partitions? The case I'm concerned about is there is a durable object instance D. There are workers A and B on different continents. There occurs a network partition between worker A, worker B and object instance D. Worker A can talk to instance D and worker B can not. Worker A tries to get a reference to object instance D and gets an existing instance. Worker B tries to get a reference to object instance D and because of the network split, fails. Worker B creates a new durable object E from the last (probably async) replicated storage to instance D. Worker A and Worker B write to their corresponding durable objects and now there is an irreconcilable conflict. A couple questions: 1. Which durable object becomes the source of truth after the network partition is healed? Are writes to the secondary object lost? It seems like only the application can reconcile this conflict and I don't see how the application does this with the current api. 2. How does the replication of storage happen so when there is a failure to find an existing durable object instance a new instance can be instantiated? When are writes to the durable object durable in the replica? After storage.put? Asynchronously?

Also how does d1 handle the above?

have you read https://developers.cloudflare.com/workers/learning/using-durable-objects/#global-uniqueness

Ahh I see so in the face of a network partition one of the worker writes would fail. Regarding 2: how does replication of storage happen? I assume storage.put returns once a write is committed to the local disk and writes are replicated asynchronously. Is this right? At what point are durable objects moved from a failed colo or pop? Is this a manual action? Will writes ever be lost if a colo / pop disappears (for more than a few second failure) before writes are replicated?

Hello, I have some questions: 1. Would a DO be suitable as a user session? like, a DO is created after login and keeps the user data, and the DO's ID is used as a session ID in a cookie. 2. If the ID gets lost somehow, will the DO delete itself eventually?

1: Could be fine as one yes 2: If theres nothing in the storage it would but you would want to save storage so they can keep their session. You can use an alarm that gets increased anytime the session is in use and once the alarm finally does get called you can call storage.deleteAll() which will remove all storage and eventually that DO ID will be removed

I see, ok. But in a different scenario, if I have a DO with saved storage, and I have lost the ID, then what would I do? Will it stay in memory forever?

As long as a DO has storage it will always exist, but it wont be active. DOs are only active while processing a request then they spin down once requests stop for a few seconds.

So you wont be charged compute for objects that you are not requesting but you will be charged for the storage until deleted

Yes, this is what is troubling me. How would I delete storage for DOs that I don't have an ID for anymore?

Theres a way to list IDs using the api

Ah, ok. Great! Thanks for the help!

Hmm... A "time since active" for each DO would have been useful in that list, so that it could be filtered on "over an hour ago" and similar. Is there such information for each DO?

Or would I have to delete every DO just to clear all the unused ones?

you would have to save the last active time yourself to know when it was last active atm