不要直接调用 Durable Object 的 alarm 处理函数

要点

• 他的 Durable Object alarm 负责清理 7 天前过期的购物车。alarm() 结束时调用 _setNextAlarm()，_setNextAlarm() 发现过期购物车时又直接调用 alarm()。一个用浮点时间戳比较，另一个用 Math.floor 后的值比较，于是在一秒的窗口内，某个购物车满足调度条件却在清理时看不到，两者来回调用、栈不回退，直到对象达到 128 MB 上限被终止。
• 他说这让一个大多只读单行的购物车 API，在过去 30 天的 191,000 次请求中产生了 80 亿次数据库操作，修复只需要两行。
• 他的建议：不要直接调用 alarm 处理函数，而是调用 setAlarm() 让运行时去触发，这样调度错误会在日志里表现为一个慢循环，而不是内存耗尽被终止。

原始来源

1. 发布2026-09-03

   原帖

   到 𝕏 阅读

   Jamie Barton（@notrab）说，一个会自我重排的 alarm 里把 `<=` 写成了 `<`，30 天里让 191,000 次请求产生了 80 亿次数据库操作；他的教训是调用 setAlarm()，而不是直接调用 alarm()。

   Jamie Barton 🥕

   @notrab · 𝕏 原帖

   If you have a Durable Object alarm that reschedules itself, go and read it. I wrote `<` where I meant `<=`. It has cost me 8 billion database operations across 191,000 requests in the last 30 days on a cart API that mostly reads a single row 😫 A Durable Object alarm sweeps carts that expired 7 days ago. alarm() calls _setNextAlarm() when it finishes, and _setNextAlarm() calls alarm() when it finds an expired cart. One compared the timestamp against a float, the other against Math.floor of it, so for a one second window a cart could satisfy the scheduler and stay invisible to the sweep. The two ping-ponged with no stack unwinding until the DO hit its 128MB limit and Cloudflare killed it. Two lines to fix. The one worth passing on!!! don't call your alarm handler directly!!! Call setAlarm() and let the runtime invoke it, so a scheduling bug shows up as a slow loop in the logs and never as an out of memory kill. I can't even blame vibe coding for this one...

   2026-09-03 16:43:23 UTC