在任务调度系统中，当任务计划在预定时间执行但任务队列已满时，系统通常会进行重试，但重试策略的设计直接影响到系统的稳定性和效率。本文将详细分析一个在任务调度系统 KernelSU 中发现的关于任务重试机制的问题，并提出相应的解决方案。

问题概述

在 KernelSU 的任务调度系统中，当任务计划执行时间到达而任务队列已满时，系统会将任务推迟 1 分钟后重试。然而，这种推迟被错误地当作新的基准时间，导致后续每次执行都跟着偏移，从而影响任务的正常执行节奏。

代码位置

这个问题可以在 backend/src/schedules.rs 文件的 run 函数中找到，特别是在处理 AppError::Busy 错误的分支中。

问题细节

  1. 在处理 AppError::Busy 错误的分支中，系统将 next_run_at 设置为 now + BUSY_RETRY_MS。
  2. 在下一次任务执行时，系统读取到的 due 值已经是这个被推迟后的时间，因此 following(due, interval, now) 函数会基于这个被推迟的时间来计算后续的任务执行时间。
  3. 由于 request_key = schedule-{id}-{due} 也随着 due 的变化而变化，这与注释中所述的“重试同一个槽位”不一致。

示例说明

假设有一个每 60 分钟执行一次的任务，首次计划在 10:00 执行。如果在 10:00 遇到任务队列满，任务将被推迟到 10:01 执行。之后，任务将在 11:01 和 12:01 执行。如果再次遇到队列满的情况，任务将再次推迟，导致执行时间不断偏移。

期望行为与解决方案

理想情况下，任务应该只推迟本次执行，而不改变原有的执行节奏。为了解决这个问题，我们可以修改 run 函数中处理 AppError::Busy 错误的分支，确保 next_run_at 的设置不会影响后续任务的执行时间计算。同时，建议增加一个测试用例来覆盖 Busy 路径，确保问题得到有效解决。

通过这些修改，我们可以确保任务调度系统的稳定性和效率，避免因任务重试机制设计不当而导致的执行时间偏移问题。