Author

Milan Miladinovic <milan@cloudflare.com> 2025-12-03 16:51:16 -0500

Parents

9265e7d

Tree

c8e3544

Increment alarmVersion more selectively

We missed a couple of places in the previous alarms fix commit, like
deleteAll. Furthermore, we probably only want to be incrementing the
alarmVersion if setAlarm() actually provided a new value, since calling
setAlarm(T) when T is already the set alarm is a no-op. This could have
posed a problem, namely, if I move an alarm later from T to T + 10, and
I call setAlarm(T + 10) multiple times, then each time that would
increment the alarmVersion, but only the first call would trigger a
commitImpl. The first commit would determine that its
alarmVersionBeforeAsync was less than the current alarmVersion, and
would assume a subsequent commit would handle any alarms, but there
wouldn't be any more commits so we would just fail to schedule the alarm
with the alarm manager.

Luckily, this would only affect move-later alarms, which don't have to
sync with the alarm manager immediately.