在模块教程 KernelSU 解决方案中，我们遇到了一个关于任务调度的问题，具体体现在 backend/src/schedules.rs 文件的 run 函数中，当遇到 Err(AppError::Busy) 错误时，代码将 next_run_at 设置为 now + BUSY_RETRY_MS，而忽略了原始的 due 值。这导致后续的 following() 函数继续使用这个被修改过的值，从而造成每次执行任务时都存在相同的偏差。

具体的行为表现如下：

  1. 新建一个计划任务，首次执行时间为 10:00，间隔设置为 60 分钟。
  2. 在 10:00 时，人为使队列处于满状态，模拟系统繁忙的情况。
  3. 当队列恢复后，计划任务应该在 10:01 执行，但由于 next_run_at 被错误地修改，任务实际上会在 10:01 之后执行。
  4. 这种偏差会持续累积，导致后续的执行时间依次推迟，如 11:01、12:01 而不是预期的 11:00、12:00。

此外，还有一个附带问题，即 request_key 包含 due 信息，在任务重试时，request_key 的值会改变，这与“重试同一个槽位”的注释相矛盾。

针对上述问题，我们期望的解决方案是只将本次触发任务延后，而不是影响后续的执行计划。具体的建议包括：

  • 可以单独保存重试时间，以便下次重试时使用。
  • 在任务成功执行后，应按照原始的 due 值来计算下一槽位的执行时间。
  • 建议补充关于 Busy 路径的测试，以确保系统的稳定性和准确性。