[DO] Adding alarm limitation when working in local dev. #20000
Conversation
github-actions
bot
added
the
product:durable-objects
|
Preview URL: https://cde753b7.preview.developers.cloudflare.com Files with changes (up to 15) |
Co-authored-by: Pedro Sousa <[email protected]>
|
|
||
| ## Alarms in local Development | ||
|
|
||
| Currently, when developing locally (using `npx wrangler dev`), Durable Object [alarm methods](/durable-objects/api/alarms) may fail after a hot reload (if you edit the code while the code is running locally). |
There was a problem hiding this comment.
@lambrospetrou I don't see this behavior where alarm methods work if no hot deploy. I'm not making code edits
https://paste.cfdata.org/JQ6bKUqtiYtrTKY3sbMC is the Worker code im running
There was a problem hiding this comment.
[wrangler:inf] Ready on http://localhost:8787
BOOM :: Promise { <pending> }
[wrangler:inf] GET / 200 OK (13ms)
[wrangler:inf] GET /favicon.ico 200 OK (2ms)
ALARM :: 1739555485366
ALARM :: 1739555490366
ALARM :: 1739555495366
I added some await as well since the alarm API is officially async:
[wrangler:inf] Ready on http://localhost:8787
BOOM :: 1739555410678
[wrangler:inf] GET / 200 OK (17ms)
[wrangler:inf] GET /favicon.ico 200 OK (2ms)
ALARM :: 1739555415679
ALARM :: 1739555420679
ALARM :: 1739555425679
ALARM :: 1739555430679
Works for both versions to me.
If you set an alarm very in the future, maybe the local miniflare implementation doesn't work correctly once the DO hibernates?
There was a problem hiding this comment.
If you set an alarm very in the future, maybe the local miniflare implementation doesn't work correctly once the DO hibernates?
No, I figured out my code was incorrect. I was calling setAlarm in my constructor, forgetting that when the alarm is invoked the DO constructor is called.
Which raises a different clarifying question: is the DO constructor always called when the alarm handler runs? I see this with wrangler dev. Is it local miniflare only behavior?
Sample output:
constructor
currentCount: 0
alarm: 1739570888980
constructor
currentCount: 1
alarm: 1739570898985
constructor
currentCount: 2
alarm: 1739570908991
Our docs say: "Durable Objects alarms allow you to schedule the Durable Object to be woken up at a time in the future."
I get that if your DO is inactive, then the alarm would start up the DO, ie run the constructor. But if your scheduled alarm time occurs when the DO is already running, then what happens (I assume the constructor is not invoked)?
There was a problem hiding this comment.
Which raises a different clarifying question: is the DO constructor always called when the alarm handler runs? I see this with wrangler dev. Is it local miniflare only behavior?
Seems to be local-only behavior. With Workers Logs on my deployed Worker, I dont see the additional constructor calls.
@Oxyjun worth documenting this behavior as well, assuming its expected cc @lambrospetrou @joshthoward ?
There was a problem hiding this comment.
The constructor is called only when the DO cold starts. If an alarm is very far apart from the previous run and the DO hibernates inbetween then yes the constructor would run each time the alarm would run.
But if the alarm is much more often, e.g. every second, then the constructor won't be running for every alarm.
There was a problem hiding this comment.
It's not a problem to set an alarm within the constructor. I did that in my example case above too.
There was a problem hiding this comment.
The constructor is called only when the DO cold starts. If an alarm is very far apart from the previous run and the DO hibernates inbetween then yes the constructor would run each time the alarm would run. But if the alarm is much more often, e.g. every second, then the constructor won't be running for every alarm.
So it's not determined by whether you're using local-only vs deploy remote?
There was a problem hiding this comment.
No. Although the time until the DO hibernates locally vs remote could be different. I dont know the exact values.
There was a problem hiding this comment.
Thanks for confirming. @vy-ton I think this PR is good to merge as far as "Known issues" are concerned, let me know if you're happy to merge :D
7 participants
Summary
Screenshots (optional)
Documentation checklist