Skip to content

[DO] Adding alarm limitation when working in local dev. #20000

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Feb 19, 2025
Merged

[DO] Adding alarm limitation when working in local dev. #20000

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
134a874
Adding alarm limitation when working in local dev.
Oxyjun Feb 14, 2025
5cf1ca4
Describing the issue in more detail.
Oxyjun Feb 14, 2025
cde753b
Update src/content/docs/durable-objects/platform/known-issues.mdx
Oxyjun Feb 14, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions src/content/docs/durable-objects/platform/known-issues.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,3 +31,9 @@ For this reason, it is best practice to ensure that API changes between your Wor
The Workers editor in the [Cloudflare dashboard](https://dash.cloudflare.com/) allows you to interactively edit and preview your Worker and Durable Objects. In the editor, Durable Objects can only be talked to by a preview request if the Worker being previewed both exports the Durable Object class and binds to it. Durable Objects exported by other Workers cannot be talked to in the editor preview.

[`wrangler dev`](/workers/wrangler/commands/#dev) has read access to Durable Object storage, but writes will be kept in memory and will not affect persistent data. However, if you specify the `script_name` explicitly in the [Durable Object binding](/workers/runtime-apis/bindings/), then writes will affect persistent data. Wrangler will emit a warning in that case.

## 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).
Copy link
Contributor

@vy-ton vy-ton Feb 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

Copy link
Contributor

@lambrospetrou lambrospetrou Feb 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more. 

[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?

Copy link
Contributor

@vy-ton vy-ton Feb 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)?

Copy link
Contributor

@vy-ton vy-ton Feb 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ?

Copy link

@XpertForexTrade XpertForexTrade Feb 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩷🩷🩷

Copy link
Contributor

@lambrospetrou lambrospetrou Feb 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@lambrospetrou lambrospetrou Feb 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not a problem to set an alarm within the constructor. I did that in my example case above too.

Copy link
Contributor Author

@Oxyjun Oxyjun Feb 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

@lambrospetrou lambrospetrou Feb 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. Although the time until the DO hibernates locally vs remote could be different. I dont know the exact values.

Copy link
Contributor Author

@Oxyjun Oxyjun Feb 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


To avoid this issue, when using Durable Object alarms, close and restart your `wrangler dev` command after editing your code.
Loading