I assume that’s only on DOs then, since regular Workers might still get evicted after 30 seconds? Or am I mistaken?

Or at least they are more likely to, I assume due to traffic

The only 30 second limit on Workers I'm aware of is that after you send a response, if you've put things in

waitUntil

they only have 30 seconds to complete.

If you open a request/WS to a normal Worker I'm pretty sure you can idle for as long as you want?

I'd do some trivial testing before believing that, though 🙂

I’ll try testing tomorrow, but not 100% sure what exactly triggers an eviction, other than crash/update, so not sure I can reliably get it to happen

Also, if this is true, this should probably be updated:

Or wait, does this mean due to updates?

I think I’ve confuzzled myself. I’ll look at it again tomorrow, when I’ve slept

That is kind of a weird line. I think it's trying to say that network connections aren't 100% reliable? Like it's unlikely to me that your TCP connection will remain open for days at a time. I don't see what's special about the 30 second mark, though.

Does the websocket api in workers provide any mechanism for sending backpressure through the tcp socket? If I send really fast to a worker, messages could start pilling up in memory faster than they can be consumed leading to resource exhaustion. Is there any way to read from the websocket in the worker only as fast as my workload allows and let TCP flow control deal with handling backpressure instead of implementing it again in my app?

seems like backpressure can be accomplished through storage gates for the above ^

do storage writes coalesce and guarantee execution for

alarm()

handler as well if I don't await them? So for example if I just do

env.storage.put()

as the last line of the alarm handler is that guaranteed success before the next alarm handler would fire, or it would throw an and retry? (plz ping)

I imagine it does but I couldn't find any docs that says it does so wanted to verify 😄

I would say just await it to be safe theres no reason not to await it 🤷

what's the right way to wait for my durable object workflow to complete from my worker?

I'm trying to get a similar kind of UX to doing

await handle.result();

for a temporal.io workflow

say if I had a web interface that needed to be notified through SSE when the workflow is completed

It seems my durable object alarms are taking over a minute to be invoked when scheduled immediately (

this.state.storage.setAlarm(Date.now())

). Is this expected?

I'm not aware of any precision guarantees they have but 1 minute seems to be about average for any timed events on a lot of cloud services so not to surprising

I thought the idea of DO alarms was to be precise 🤔

Same, and I’m pretty sure when I had one repeat every 20 seconds it worked fine, within a second of the scheduled time

And the docs seems to suggest this is indeed the intended behaviour: > If setAlarm() is called with a time equal to or before Date.now(), the alarm will be scheduled for asynchronous execution in the immediate future. If the alarm handler is currently executing in this case, it will not be canceled. 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.

does anybody know a good example for a simple do counter (w/ typescript)?

docs suggest > If setAlarm() is called with a time equal to or before Date.now(), the alarm will be scheduled for asynchronous execution in the immediate future. [...] 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. (setAlarm) so it should be few ms. But also Date.now() is special cased to run immediately, so it really doesn't seem normal that it'd take more then a few milliseconds (outside of special failure events). Not my experience either.

Coming back to this after reading https://blog.cloudflare.com/durable-objects-easy-fast-correct-choose-three/. After reading that, it sounds like it doesn't matter if I update in-memory state before confirming that the storage operations succeed. If they fail, the DO is evicted from memory and my rehydrating code will restore the in-memory state from storage. @kenton , could you confirm this since you wrote the blog post?

is the recommended way to get visibility over the state of lots of durable objects (for a dashboard for example) to write the state to a database whenever you write to storage?

say each of my durable object instances represents a ecommerce transaction

and I want to inspect transactions that are in some state