添加一个定时删除执行记录的任务，max_age是最大保存时间，这里设置为7天。scheduler.add_job()用来添加定时任务，trigger是触发器，也就是计划时间，这里设置为每周一0点。id是任务的标识符。max_instances指同时最多只有一个实例。replace_existing设置为True，每次都更新已存在的任务，防止重启服务导致scheduler.add_job()报错。
启动任务。
编辑teprunner/views/run.py文件：
为了手动执行测试计划和定时任务执行测试计划共用，这里把执行代码抽取了部分作为run_plan_engine()函数。
编辑teprunner/views/plan.py文件：
重写create方法，先根据测试计划的名字判断是否已存在，如果存在就直接返回500。接着判断开关如果开启，那么就通过scheduler.add_job()添加任务。跟刚才添加任务的有点区别是，通过args参数指定了func函数的参数。最后把任务添加日志写到响应中返回。
重写update方法，先判断测试计划是否已经存在，判断规则是根据名字去查找已存在记录，如果找到同名计划，且id不是自己，那么就认为已存在同名计划，直接返回500。
然后判断如果开关打开，就新增任务；如果开关关闭，就删除任务，删除任务使用scheduler.remove_job()。
最后重写destroy方法，在删除测试计划时，一并删除定时任务。
猴子补丁解决pymysql连接问题为什么定时任务会不稳定？因为我用的pymysql库，它不会进行数据库连接断开后重试。Django和MySQL建立建立后，何时断开连接通过CONNECT_MAX_AGE来设置，默认是0，表示使用完马上断开连接。Django只会对Web请求采取这个策略，使用signals.request_started.connect(close_old_connections)和signals.request_finished.connect(close_old_connections)来关闭旧连接。但定时任务不是Web请求，而是直接连接数据库，Django并不会去主动断开这个连接。而MySQL默认8小时会把连接断掉，于是当Django拿着已经被MySQL断开的连接对象去请求MySQL，就报错了。
当我在本地安装了MySQL后，重启MySQL就能复现这个问题。
解决办法一是把旧连接复活，进行断线重连，但是会导致连接占用可能越来越多，耗费资源。解决办法二是像Django处理Web请求一样，每次用完就断开，下次使用再重新连接，占用资源少。
猴子补丁是指不修改第三方库的基础上，对库的功能进行扩展。我给django-apscheduler写了个猴子补丁，实现第二个解决办法，用完就断开连接：
并且通过issue方式，告诉了它的作者：
这开启了我在GitHub上英文交流技术的大门。
比如我又给loguru提了个bug，此时已经和loguru的作者英文交流了5个回合。
小结