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

重现问题的方式如下：

  • 首次计划执行时间为 10:00，间隔设置为 60 分钟。
  • 在 10:00 时，任务队列满，导致任务在 10:01 执行。
  • 之后任务的执行时间变为 11:01、12:01，以此类推。

期望的行为是：

  • 重试只影响当次执行，之后的执行时间应保持为 11:00、12:00 等。

建议的解决方案：

  • 将重试时间与槽位时间分开保存，以避免重试时间影响后续的执行计划。
  • 为处理 Busy 错误的路径增加单元测试，确保代码逻辑的正确性和稳定性。