APScheduler 失火测试

Question

我正在尝试使用 APScheduler 测试失败的任务，但是当我重新启动 APScheduler 时，我没有看到错过的任务运行。我已将 APScheduler 配置如下：

scheduler.py

def configure_scheduler():
    jobstores = {
        'default': SQLAlchemyJobStore(url=config('DATABASE_URL'))
    }
    sched = BlockingScheduler()
    sched.configure(jobstores=jobstores)
    sched.add_job(
        test_task,
        id='test_task', 
        'interval',  
        hours=1, 
        coalesce=True, 
        max_instances=1,
        misfire_grace_time=360, 
        replace_existing=True
    )
    return sched

if __name__ == '__main__':
    scheduler = configure_scheduler()
    scheduler.start()

当我第一次启动调度程序时，test_task 被添加到我的 Postgres 数据库中的 apscheduler_jobs 表中，next_run_time 从我启动调度程序开始一小时。然后我尝试通过以下方式测试失火：

1. 将我数据库中的next_run_time 更改为当前时间
2. 等待 15 秒
3. 启动调度程序

当我按照这个程序进行操作时，next_run_time 再次设置为距当前时间一小时。 next_run_time 似乎在 SQLAlchemy 作业存储的 update_job 方法中更新。我见过一个similar question 与在失火后未运行的持久作业存储任务相关。我见过的大多数otherquestions 的解决方案是将misfire_grace_time 参数添加到add_job。我已经按照上面的配置进行了尝试，但是在调度程序启动时运行错过的作业没有任何运气。我是否遗漏了与 replace_existing 和 misfire_grace_time 参数如何交互相关的内容？我是否需要手动检查任何作业的next_run_time 是否在过去，然后在启动调度程序之前运行这些作业？

我正在使用 v3.6.1 的 APScheduler 库。

对于其他上下文，我将在 Heroku 上部署调度程序，并尝试解决 Heroku 的 automatic dyno cycling 问题，该问题每天至少发生一次。

Answer 1

在与 Alex Grönholm（APScheduler 的创建者）在 APScheduler Gitter 聊天室中 some discussion 之后，我能够确定该作业在我的数据库中被“覆盖”，因为我在对 @ 的调用中有 replace_existing=True 987654323@。这会导致调度程序在每次调度程序启动时替换作业存储中的作业。

我的解决方法

1. 在调度程序启动之前，检查apscheduler_jobs 表中的现有作业。

2. 对于数据库中的每个作业，检查 next_run_time 与当前时间。如果 next_run_time 是过去的，请立即运行该作业。

3. 像以前一样安排作业，使用replace_existing=True。

4. 启动调度程序。