 ThearchyHelios
|
45fe01effe
|
定时任务自动对比复核整改（后端）：只比成功的运行、按发起先后挑上一次成功的基准、和两边的封存绑定，对比挪到认领之前在锁外做并限时限并发；失败通知的处理行不再重复原因
- 只比成功结束的运行，基准也只取成功的：失败、取消的运行指标不全，和上一次比只会得出「移除 N 个」，拿失败的那次当
基准每个指标都成了「新增」。基准改成自己查同一定时任务、同一工作流、比这次先发起的运行里成功并封存的最近一次，
不再用对比接口的 default_base（按结束时间挑：老的失败运行事后被接着跑完，会拿后一次触发当它的「上一次」）。
中间隔着失败、取消的运行时，通知写「与上一次成功的运行（#短编号，日期）相比」，Fire.compare 多一个 previous
- 和封存绑定：运行的封存要盖住最后一条结束事件才算封存完（sealed_now）。runner 先写终态、再另起会话封存，失败后
接着跑完的运行在两步之间还带着失败时的清单哈希，以前这一拍会直接认领、按旧封存比、通知里写旧的清单哈希；现在
等新的封存，等不来就照常推送但不比、不写哈希。停在审批上的通知也不再写失败时留下的哈希。对比工件连同两边的清单
哈希一起存，触发历史发现任何一边不在终态或清单哈希变了就给 null；对比途中封存变了不记（条件写）
- 时机和时限：锁里只挑出状态有变化的触发，认领挪到对比之后、锁外按条件 UPDATE 做。对比最多等 20 秒（含排队），
同一时刻最多 2 个；超时只记警告，通知不带对比照常推送。停机时扫描在对比途中被取消，这次触发还没认领，下次照常
比、照常推（以前先认领、后比，这条通知会永远丢掉）。同一份封存已经比过的直接用记下的结果
- 失败通知：从没开始执行的，原因刚写过，处理行不再让人「查看原因」，任务在排期上写「下一次触发会照常发起」，停用
的写怎么重新发起；开始执行过的改成「请在 AgentLab 的「记录」中查看失败原因」，和挂起那句指向同一个导航入口
- 新增 test_scheduler_compare_guards.py（封存绑定、时限、取消、并发、复用），test_scheduler_compare.py 补真实缺
指标的失败运行、上一次失败、补跑老运行几种用例；去掉实现逐项验证过会变红
|
2026-10-06 08:48:56 +08:00 |
|
|
ThearchyHelios
|
f0f1b99ead
|
定时运行结束后自动和同一定时任务的上一次对比：结果存成工件记在触发记录上，触发历史和通知只给计数摘要与对比页链接
- 新增 app/scheduler/auto_compare.py：通知扫描认领到运行进入终态（结束、失败、取消）的那一次之后、推送之前，
调运行对比接口的现成函数（default_base、compare_runs，不改它们）比一次。基准只取 default_base 的「同一定时
任务」那一档，退回「同一工作流」的不比——那不是这个任务的上一次。没封存的不比；比不了（基准封存核对不一致等）
记警告、意外异常记堆栈，都不影响通知。整份结果存成 run_compare 工件，不挂在运行名下（不进运行的工件列表），
工件 id 写进 ScheduleFire.compare_artifact；再次进入终态（失败后继续执行）时按新的封存重新比、覆盖旧结果
- 接口：Fire 多一个 compare: {base_run_id, summary}（summary 同对比接口的计数）或 null。运行现在不在终态
（被继续执行）、工件读不出来时为 null；工件摘要按 id 缓存（内容寻址，不会过期），读盘在线程里
- 通知：结束、失败的通知多一行「与上一次相比：只数据变 3 个、口径与数据都变 1 个、SQL 结构变 0 个」（三类总写，
其余各类有才写，两边都没有指标时不写一串 0 个），配了对外访问地址时附对比页链接（/runs/compare?target=…&base=…），
四种格式都带；通用格式多一个 compare 字段。只给个数，不放任何具体数字
- 没配 Webhook 的任务也比：触发历史里要用
|
2026-10-05 18:45:59 +08:00 |
|
|
ThearchyHelios
|
d62f921ed4
|
定时任务遗留问题：失败通知不再许诺能继续运行、30 天前的触发停在审批上照样推送、调度循环测试不再依赖整分边界
- 失败通知的「处理」行改成中性的「请在 AgentLab 的运行记录中查看原因」：服务重启时还在排队、从没开始执行的运行
没有断点，「修正后可继续运行」是错的；开始执行过的也可能续不了（执行第一个节点前就失败、系统升级后断点不兼容），
能不能继续以记录页为准。没有开始时间的失败另写一行原因（没有可继续的进度），通用格式的 reason 字段同写；任务
还在排期上时补「下一次触发会照常发起」，和挂起（之后的触发都跳过）说清区别
- 通知扫描的 30 天窗口加两种例外：停在审批、有待审批的运行不受限制（创建 30 天以后才停到审批上的以前收不到
「等待审批」）；运行记录 30 天内有过变化的照扫（等了一个多月的审批批完、跑完，以前收不到「运行结束」）。早就
结束、多日没有变化的旧触发仍不扫
- test_loop_ticks_until_stopped 改成只看「发起了」和停下前后的条数差：建任务和第一拍之间跨过整分时会先记一条
错过的跳过，以前按总条数断言偶发失败。加一组把下一次放在上一个整分的用例，必然走到跨整分这一支
|
2026-10-05 18:39:10 +08:00 |
|
|
ThearchyHelios
|
a9d7cba884
|
定时任务复核修正（第 1 轮）：重启挂起的运行不再让任务静默停摆，格式选错、地址发不出去时照实报，整份回写不再丢掉到点的触发
- 挂起：上一次运行在服务重启时被挂起（interrupted、没有待审批）不会自己接着执行，之后每次触发都按重叠跳过，原因写
「还没有结束」，一条通知也不推，任务就此静默停摆。interrupted 照规格仍算没结束，但跳过原因按挡路的运行分三种写
（仍在进行中、正在等待审批、已挂起并请在「记录」中继续运行或放弃），运行编号写成界面上的 #前 6 位，去掉「按设置」；
挂起的那次按 failed 事件推一次，写明原因和处理办法，不是每次触发都推。停在审批时每停一个审批点推一次（已处理状态
带上第几段执行，以前第二个审批点不再推）；审批刚批完、还没接着执行（answered）不当挂起
- 没有结束时间的失败运行（服务重启时还在排队、被改成 failed）永远不会封存：等封存改按最后更新时间算，以前按「现在」
等，每一拍都等、永远不推
- 平台错误码按地址的主机认，不看所选格式：格式和地址对不上时，测试显示「已送达」、正式推送记成功，群里却收不到；
现在记失败并带上平台的错误码。群机器人的地址（飞书、企业微信、钉钉）保存时要配它平台的格式，否则 422；格式省略时
按地址认。只在地址或格式真改了时查，库里已有的旧设置不挡停用、改名
- 地址校验：端口不是 1 到 65535 的数字、夹着空格或不可见字符（零宽空格、控制字符）、httpx 建不了请求的（主机名不合
IDNA 规则）保存时就回 422 和中文说明；推送时另兜住 InvalidURL 和其他异常，测试接口不再回 500 或英文报错；端口写错
的地址也照样取出主机名
- PATCH 看值变没变，不看键在不在：整份表单回写不再重新校验没改的工作流（工作流删了也能停用），cron、时区、启用状态
真改了才重算下一次触发。启用着改 cron、时区时，从原来那个到点的时刻接着算，新表达式也覆盖那一刻就还发起这一次。
补两人同时保存的测试，证明条件 UPDATE 守住了乐观锁
- 发起中的占位：接口读到正在发起的触发按「已发起」给（run_id 为空），不再闪一次「未能发起：服务在发起运行前停止」；
库里仍先写占位，进程被强杀时照实说没有发起
- stop：先置停止标志再取任务，这一拍收尾不再新起通知扫描（以前会落下一个不在等待名单里的通知任务）；循环和通知两件
事并行等，宽限缩到 3 秒和 1.5 秒，给关停时的 run_manager.shutdown 留出 docker stop 的大半时间
- 通知正文：立即运行写「手动触发」，补发标明「错过后补发」；失败不再写「原因：运行失败，详情请查看运行记录」，改写
失败节点的名字和处理办法；状态叫法和界面一致（等待审批，已挂起，可继续运行）；「封存哈希」改叫「清单哈希」，运行
编号写 #前 6 位；测试消息只说收到它证明得了的事（企业微信、没配密钥时不提签名）。测试接口的 message 改成 ok、
http_status 之外的补充说明（送达时提醒去接收端确认，失败时是原因），前端接在「测试消息已送达（HTTP 200）」后面不再重复
- 422 文案：不回显 Python 的值（None 写「未填写」，列表不原样回显、点出不认识的那一项），格式、事件写中文名；
copy-allow.json 为平台名「钉钉」加一条（和前端包为 terms.ts 加的那条并存，试合并不冲突）
- test_loop_ticks_until_stopped：下一次放在整分上、只认发起的那一条，去掉约 1/60 的偶发失败
- 逐个做过变异，改回后对应测试都变红：挂起不推、跳过原因退回旧写法、没结束时间按现在等、错误码只看格式、去掉版本
条件、到点保留和值比较一起去掉、不屏蔽发起中的触发、stop 既不查停止标志也不兜底、answered 当挂起、审批状态不带段号、
不建请求校验地址、保存时不查格式
|
2026-10-05 10:00:25 +08:00 |
|
|
ThearchyHelios
|
a2a19df9df
|
定时任务后台：三张表、输入模板、调度循环和 Webhook 推送，设置加「通知」一组
- 表：schedules（Webhook 地址和签名密钥加密存放、next_run_at 存 UTC、version 乐观锁）、schedule_fires（(任务,
fire_at, kind) 唯一）、webhook_deliveries；新表由 create_all 建，不用迁移
- 输入模板：{{ schedule.yesterday }} 这类变量按计划触发时间在任务时区算（不按「现在」：补发晚了、零点前后立即
运行，「昨天」都是那次触发的昨天），上一次计划触发时间按 cron 往前找，同一次触发永远渲染出同一份输入；未知
变量、未知过滤器、{{ }} 不成对都拦下，声明了入口字段的工作流还对照字段名和必填项
- 调度循环：每 15 秒一拍，条件 UPDATE 认领到点的任务并推进到下一次，两拍并发只有一拍认领得到，触发记录的唯一
约束是第二道保险；上一次运行没结束（含停在审批、服务重启挂起的）记跳过；错过的只看最近一次，在宽限内补一次、
超出记跳过，积压不补；发起走 launch_run，拒绝的原话记成未能发起，别的异常记通用说明、详情进日志；stop 等手上
这一拍收尾，开关关着时 start 不起循环
- Webhook：通用 JSON（可选 HMAC 签名头）、飞书文本、企业微信 markdown、钉钉 markdown，按各平台算法签名；运行
结束、失败、确有待审批时按订阅推一次，结束的等封存好再推，没订阅、没配 Webhook 的也记下已处理，之后配上不会
补推旧的；10 秒超时、失败重试 3 次（4xx 不重试），每次推送记一条记录；通知里没有报告数字和原始报错，日志和
错误里只有主机名（httpx 自己的请求日志也换成主机名）
- 设置 notify.public_base_url：通知里的运行链接 = 它 + /runs/{id}，只收 http(s) 地址，末尾的 / 去掉
|
2026-10-05 08:37:57 +08:00 |
|