whyour
f168efcdae
refactor: migrate cron scheduling to node-cron ( #3079 )
...
* refactor: migrate cron scheduling to node-cron
* feat: support annually midnight and minutely cron macros
* fix: harden cron recovery and system scheduler compatibility
2026-09-27 22:18:39 +08:00
Martha Ramirez
a942a5686f
修复删除定时任务后 crontab.list 残留导致订阅更新无法重新注册 ( #3021 )
...
* 修复删除定时任务后 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 容错。
2026-06-30 23:48:51 +08:00
whyour
07951964a1
修复模块注入
2025-10-26 22:32:03 +08:00
whyour
acc7443004
定时任务支持多个定时规则
2023-09-16 00:15:50 +08:00
whyour
4f7649f157
系统设置增加系统运行日志
2023-08-21 00:10:43 +08:00
whyour
6fb39ce835
重构六位定时任务服务
2023-04-08 17:07:06 +08:00
whyour