https://blog.cloudflare.com/durable-objects-alarms/ > Under the hood, Alarms are implemented by mak

https://blog.cloudflare.com/durable-objects-alarms/

Under the hood, Alarms are implemented by making reads and writes to the storage layer. This means Alarm 
get
 and 
set
 operations follow the same rules as any other storage operation

The DO alarm's blog post references the storage blog post:

https://blog.cloudflare.com/durable-objects-easy-fast-correct-choose-three/#part-2-output-gates

From what I understand of this blog post, the following would be how things would play out? Which doesn't seem to align with <any failure within the alarm handler causes all alarm calls in that call to be ignored and for the original to be retried>

alarm() {
  await setAlarm() // This would be committed (and therefore overwrite the initial alarm? what happens to retries?)
  await someOtherStorageOperation() // this too given no failure up until the first fetch
  await fetch(...external) // Output - gates mean we now wait for previous operations to succeed

  await setAnotherAlarm() // This would not be committed because of subsequent failure (write coalescing)
  await triggerSomeFailure()
}
Was this page helpful?