在模块教程 KernelSU 解决方案中，我们遇到了一个关于任务调度的问题。具体来说，是在 backend/src/schedules.rs 文件的 run() 函数中处理 Busy 状态时出现的代码问题。当队列繁忙时，现有的重试逻辑将计划的 next_run_at 直接设置为当前时间加1分钟。这导致下一次运行时，due 值被设置为这个新时间，而 following() 函数是基于 due 来构建时间网格的。因此，时间网格被错误地调整，且无法自行恢复正常。

问题描述中提到的一个重现场景是：任务计划每60分钟执行一次，首次执行时间为10:00。如果在10:00时队列已满，任务会被重新计划到10:01。实际执行时间会变成10:01、11:01、12:01等。如果再次遇到队列满的情况，任务的时间会进一步偏移。

此外，还有一个相关的问题：request_key 是使用 due 来拼接的，在重试时 key 会发生变化，这与代码注释中关于“同一个槽位”的描述不符。

对于这个问题，我们的期望是重试不应改变时间网格，而只应推迟本次执行。目前，针对这一路径还没有相应的测试。为了解决这个问题，我们需要重新设计重试逻辑，确保在队列繁忙时，任务的重试不会影响时间网格的构建，同时保证 request_key 在重试时保持不变，以符合代码注释的描述。