在阅读 backend/src/schedules.rs 文件时，您遇到了一个时间计算的问题。当计划执行的时间到达，但任务队列已满（即返回 AppError::Busy）时，代码会将 next_run_at 更新为当前时间加一分钟。这意味着下一次执行时，这个被修改的时间会被当作该槽位的 due，而 following() 函数会从这个时间点开始推算下一次执行时间，导致 first_run_at + k * interval 的节奏被永久平移。由于 request_key 中也包含了 due，因此重试并不是真正在“同一槽位”执行。

重现步骤：

  1. 首次计划执行时间为 10:00，间隔设置为 60 分钟。
  2. 在 10:00 时任务队列已满，任务在 10:01 执行。
  3. 之后任务分别在 11:01 和 12:01 执行。

期望结果：
重试应该只影响当次执行，之后的执行时间应该仍然是 11:00 和 12:00。

建议解决方案：
为了解决这个问题，建议将重试时间与槽位时间分开保存，这样可以避免重试时间影响到后续的执行计划。同时，为 Busy 路径增加测试用例，确保在任务队列满的情况下，时间计算逻辑是正确的。