mirror of
https://github.com/whyour/qinglong.git
synced 2026-07-17 09:34:31 +08:00
Martha Ramirez
a942a5686f
* 修复删除定时任务后 crontab.list 未同步导致订阅更新无法重新注册脚本 crontab.list 作为数据库的文件镜像，其同步 setCrontab() 此前串行在尽力而为 的 gRPC addCron/delCron 调用之后：当调度 worker 重启等导致 gRPC 短暂不可用、 addCron/delCron reject 时，setCrontab() 会被跳过，crontab.list 与数据库脱节。 而 shell/update.sh 的 gen_list_repo() 将 crontab.list 作为"已有任务"真源， 于是订阅更新误判脚本已存在、跳过新增注册（前端再也看不到这些脚本）。 将 create/update/remove/disabled/enabled/autosave_crontab 中的 gRPC 调用改为 尽力而为（try/catch + 告警日志），保证 setCrontab() 总是执行；autosave_crontab 额外将 setCrontab 提前到 addCron 之前，确保启动/调度器重启时文件总是同步， 并避免 gRPC 失败导致应用启动崩溃。 调度器内存中的任务注册与 crontab.list/系统 crontab 同步是两个相互独立的关注点： gRPC 失败时内存调度可能在调度器重启后由 autosave_crontab 重新注册，但文件同步 不应因此被阻断。修复后既有的 crontab.list 残留会在下次重启或任意增删改时自愈。 可能与 #2422（订阅更新重复添加任务）同根因。 * 过滤 delCron 中 scheduleStacks 的 null job nodeSchedule.scheduleJob() 对无效 cron 表达式（如 "0 * /6 * * *"， 空格分开了 * /6）会返回 null，原代码原样存入 scheduleStacks 数组。 delCron 取消时对 null 调 cancel() 抛出 UNKNOWN 错误，导致 gRPC handler 中断、HTTP 端 cronService.remove() 跳过 setCrontab()， crontab.list 残留已删任务的记录，导致订阅更新时 gen_list_repo() 误判脚本已存在、不再重新注册。 过滤 null 并对每个 cancel 调用加 try/catch 容错。