durable object alarms seem to be running more than once at a time with --local

^ this seems to be happening for sure, no issues when I push the worker to staging

do alarms get "queued"? what I'm wondering is if you are inside an alarm handler would there be a difference between setting an alarm for now vs setting an alarm for 5 minutes if the current alarm handler will take 10 minutes?

Alarms don’t get queued they overwrite each other you can only have 1 alarm set. As far as the behavior of setting an alarm while one is running I have no idea how that works 🤷

seems to work. but I am seeing some really weird behavior. is there any situation where

this.state.idFromName

would be

undefined

in an alarm handler? when the alarm handler is running and there is an alarm set to be run and new code is deployed, it runs the next alarm after the deploy but

this.state.idFromName

is

undefined

and the alarm on the original DO is never run

Im not sure when it is defined, afaik it wasnt ever even supposed to exist there in the first place. But perhaps they define it whenever you make a fetch request with a stub that you get by called idFromName

the main problem I'm running into is that the alarm doesn't seem to get retried when the handler is still running and new code is deployed

not sure best way around this

I'll need to create a whole other DO to keep track of my other DOs if I can't find a better way around this 😦

it might be because I'm setting another alarm in the handler so let me check that

Is the error being thrown in the alarm handler? If not it cant really retry as it thinks it was successful after delivery. It is possible theres some bug around that though, and if so and can some-what easily be repro'ed we can put in a report of it to be looked at

yeah in the handler

another DO with a

null

idFromName

alarm gets called immediately after the error

I'm using

itty-durable

, not sure if that is somehow causing it

I dont think idFromName is even supposed to exist there at all on the object and only on the stub.

https://github.com/kwhitley/itty-durable/blob/v1.x/src/itty-durable.js#L113 gets added here

it is always defined except in this one very weird scenario where I deploy code when an alarm handler is running

that somehow triggers an alarm where its null. not sure what I'm missing 😦

Ok so its exactly as I said. Itty is adding the idFromName value if you call

fetch

on a stub that you got using

idFromName(<name>)

. Basically it will never be there for an alarm unless it happens to still be active after a fetch request.

ah

so what is a reliable way to get the DO's id?

oh here is the other thing though: the storage is blank on the object

the name or the id? The id is this.state.id The name you would need to pass on fetch and save into storage

the name I mean

I checked and the storage was blank

maybe itty-durable issue?

if you arent saving anything to storage the storage will be blank

no these DOs have a lot of data in them

it was reset to the default values from the constructor