Scheduling Priority Mechanism: Dynamically configure queue jumping by project/PR type (owner requirement) | 调度优先级机制:按项目/PR类型动态配置插队(owner 需求) #15

🤖 Powered by ework

来源: dog/ework-aio#3(旧 Gitea http://[internal-ip]:3300/dog/ework-aio/issues/3)处理「b-c#1673 如何插队」时,由 owner 提出需求。

需求(owner 原话)

「可以搞一个插队机制 按照项目 pr 类型设置优先级 可以搞灵活一点不要太死 可以动态配置」

即:调度优先级不再纯 FIFO,支持按 项目 / PR 类型等维度配置优先级,规则可动态调整,不写死。

现状

• engine 取队列:SELECT ... WHERE status='pending' ORDER BY created_at ASC(packages/daemon src/op.ts:319/327),纯 FIFO,无任何优先级概念;
• 今天为了插队 b-c#1673(release PR)只能改 messages.created_at 手术(dog/ework-aio#3 有记录),不可持续。

设计草案

1. 取件排序改为 (priority DESC, created_at ASC);messages 加 priority 列(默认 0),入队时按规则求值一次,之后不变(可被单 issue boost 覆盖)。
2. 规则引擎:规则存 web config 表(akey 如 queueRules:global),JSON 数组,按序匹配首个命中:
   [{match:{project:"ranxianglei/billion-context", kind:"pr", titleRegex:"^\\[PR\\] release"}, priority:10}, ...]
   • match 字段可选:project / kind(issue|pr) / author / titleRegex;
   • 项目设置页提供编辑 UI(对齐现有 🤖AI 设置区),60s 生效、免重启;
   • 规则改了只影响之后入队的消息(已在队中的按入队时值,语义简单可预期)。
3. 单 issue 手动插队:web issue 页加「⚡优先」按钮 → 该 issue 后续入队消息 priority=100(或 UPDATE 队中消息,二选一定稿);再次点击取消。解决「现在这一单很急」场景,不必动规则。
4. 兼容性:不配置任何规则、不点按钮 → priority 恒 0 → 行为与现状逐字节一致(回归零风险)。
5. 可观测:排队 ⏳ 系统评论附带「队列位置 #N / 共 M」;web issue 列表显示排队位次,用户不再靠猜。

验收建议

• 单测:同优先级严格 FIFO;高优先级后到先跑;规则 60s 热生效;无配置行为不变;
• e2e:灌一批低优先级 + 一条命中 release 规则的 PR 消息,断言后者先 spawn;
• UI:规则编辑 + ⚡按钮各一条手动路径。

涉及面

daemon(取件排序+priority 求值)、web(config UI+⚡按钮+排队位次)、aio(如需 env 开关 WORK_QUEUE_PRIORITY=off 兜底)。

Mirrored from ework issue #15