automation/approvals: 多副本集群下审批流每级节点(除首级)被重复创建 —— approve 后恢复读到滞后一拍的流运行态,同级要批两次(单副本零重复)

[baozhoutao]

TL;DR(人话)

多副本集群(redis 集群驱动 + LB 轮询)下,flow 审批流每一级审批(除第一级)会被重复创建一次:核准当前节点后,平台重建了同一个节点(同 flow_run_id、同 flow_node_id 出现 approved + pending 两行),同一审批人要把同一级批两遍才能推进。单副本同库同流零重复。流最终能走完、终态正确,但审批人会看到重复待办。

版本与环境

• objectos-ee 镜像 4.1.1(内建 runtime 17.2.0),@objectstack/automation / @objectstack/service-cluster-redis 随镜像
• 拓扑:traefik 轮询 → 3 个 app 副本,共享 postgres:16 + 共享 redis:7,OS_CLUSTER_DRIVER=redis
• 单副本(停掉 2 个副本,同一库)对照:零重复 —— 集群特有

最小复现

任意 record_change 触发的多级审批流(复现用的流:三级,节点 lv1→lv2→lv3,approvers 分别为 field / position / position):

1. 提交记录触发流 → 建 lv1 审批请求(恰 1 张,这一步正常);
2. 核准 lv1 → 正常推进,建 lv2;
3. 核准 lv2 → 平台又建了一个 lv2(pending),而不是 lv3;
4. 再核准 lv2(第二次)→ 建 lv3;核准 lv3 → 又建一个 lv3;再核准 → 流结束。

三级流实际产生 5 个审批节点(lv1×1、lv2×2、lv3×2)。sys_approval_request 留痕:

lv1_dept_head | approved   (同一 flow_run_id)
lv2_gm        | approved
lv2_gm        | approved   ← 重复
lv3_finance   | approved
lv3_finance   | approved   ← 重复

时间线特征:重复节点的 created_at 与上一节点的 completed_at 相差 ~60ms(核准的恢复动作当场重建了当前节点)。

判别与机理推断

• 单副本对照(同库、同流定义、新记录):恰好 3 节点零重复 ⇒ 排除流定义/项目侧因素;
• 每次核准请求经 LB 轮询落到不同副本。现象与「approve 后的流程恢复读到了滞后一拍的运行状态(副本内存缓存的 flow run 检查点未跨节点同步)」完全吻合:恢复方以为当前还在上一节点,于是把"下一节点"(=其实是刚批完的节点)再建一遍;
• 同环境启动日志有 MetadataClusterBridgePlugin: metadata service does not expose attachClusterPubSub(); cross-node cache invalidation disabled —— 疑与该缓存失效通道缺失同族。

期望

集群下核准节点 N 应推进到 N+1,不应重建 N;流运行态的恢复应以共享存储(或跨节点失效后的重读)为准,不受处理副本的内存缓存影响。

旁证(同环境其余集群面均正常)

record_change 触发本身恰跑一次(1 次提交只建 1 张审批请求);定时任务 redis fence 选主只跑一次;通知每事件恰 1 条 —— 唯独审批流的 approve-resume 链路出现滞后。

我们没有做的事

应用侧无 workaround(不吞重复节点)。当前只能接受"每级多批一次"或把审批链路收单副本。

---

Part of steedos-labs/os-project-titanwind-ehr(deploy-ee 集群实测第六轮发现;单副本对照零重复)

[os-warren]

Triage: lands in packages/services/service-automation(审批流的 approve-resume 链路)⇒ domain:services, pm:queue, type Bug, priority:p1。

证据质量:单副本对照(同库、同流定义、新记录)得 3 节点零重复,多副本得 5 节点 ⇒ 有对照的读数,已排除流定义与项目侧因素。sys_approval_request 的留痕 + 「重复节点 created_at 与上一节点 completed_at 相差 ~60ms」的时序特征,共同指向卡的推断:恢复方读到滞后一拍的运行态。

p1 而非 p0:流最终走完、终态正确 ⇒ 无数据损坏;但审批人每一级要批两遍,是生产环境用户可见的功能性缺陷,且应用侧无 workaround(卡明说只能接受重复,或把审批链路收到单副本 —— 后者不是修复,是放弃集群)。

⭐ 跨卡观察:本卡与 #13686 是同一部署的同一族,只有全仓视图看得见

本轮同批分诊到 #13686(domain:services,priority:p1):DbJobAdapter 的 interval 型调度在多副本下无 leader-election。两者:

• 同一客户部署(objectos-ee 4.1.1 / runtime 17.2.0,3 副本 + 共享 pg/redis,OS_CLUSTER_DRIVER=redis),同一立卡人,同一轮集群实测;
• 同一形状:集群协调只接通了一部分,而未接通的那部分在单副本下不可见;
• 本卡还带一条直接旁证:启动日志 MetadataClusterBridgePlugin: metadata service does not expose attachClusterPubSub(); cross-node cache invalidation disabled。

⚠️ 这是机制假设,不是裁决:两卡可能共享根因(跨节点缓存失效通道缺失),也可能是两个独立缺口恰好同源于同一次集群化。⇒ 派发令必须要求 dev 先证伪或证实这一点,并且:

• ⛔ 两卡不同批派发(同一 seam,读耦合:任一方的修复都可能改变另一方的表现);
• 先派 service-job: DbJobAdapter 的 interval 型调度在多副本下无 leader-election(cron 型有)—— #2219 声明的 interval 半边缺失,竞态实锤重复执行 #13686(根因更靠下、范围更清楚:DbJobAdapter.schedule() 的 interval 分支已定位到行),其结论作为本卡的输入;
• 若 service-job: DbJobAdapter 的 interval 型调度在多副本下无 leader-election(cron 型有)—— #2219 声明的 interval 半边缺失,竞态实锤重复执行 #13686 的修复让本卡的重复消失 ⇒ 本卡按重复关闭并记录;若不消失 ⇒ 本卡是独立缺口,证据更强。

必答项

1. attachClusterPubSub() 缺失是本卡根因还是同环境的另一个缺口?这是二值问题,先答它。
2. 「恢复以共享存储为准」是修法还是绕法?卡的期望写的是前者("流运行态的恢复应以共享存储(或跨节点失效后的重读)为准")—— 若实现上选了「加锁串行化 approve」,那是掩盖而不是修复,须回报而非自选。
3. ⭐ 卡列的旁证(record_change 触发恰一次、定时 fence 选主恰一次、通知每事件恰一条)是有价值的负向对照,说明集群面其余部分正常 ⇒ ⛔ 不要把本卡诊断成「集群整体不可用」而扩面重做。

---

Generated by Claude Code

[baozhoutao]

补充一组新的复现观察(同环境:objectos-ee 4.1.1 / @objectstack/*@17.2.0,redis 集群驱动,3 app 副本,traefik LB):

三级审批流(部门负责人→总经理岗→财务岗,三个不同真实账号逐级 approve)连跑两轮,出现另一种形态,且复现不稳定:

• 第 1 轮:三级各恰好出现 1 个待办、各 approve 1 次(与本单原始形态「同级要批两次」不同)——但第三级 approve 通过后,流程回卷到第二级又创建了第 4 条 pending 节点,单据终态停在审批中,未到 approved;
• 第 2 轮(同配置同流程同账号):三级各恰一次,干净收口到 approved,零异常。

两轮提交动作本身都只生成 1 条审批请求(提交侧无重复)。看起来与本单根因(approve 后某副本恢复读到滞后一拍的流运行态)一致,只是滞后读发生的时点不同:发生在中间级 = 同级批两次(原形态);发生在终审级 = 终审后回卷重开下游节点、流程无法终止(本次形态)。供修复时一并覆盖终审路径的用例。

[os-sales]

Claim: PM loop round 1 (services seat)
Session: session_01AUF1NoViznQK32gqpK8wS8
Branch: claude/issue-13617-approval-resume-stale-run-state
Worktree: objectstack-issue-13617
Domain: domain:services
File surface: packages/plugins/plugin-approvals/src/** and packages/services/service-automation/src/**; diagnosis may READ packages/services/service-cluster/** but any WRITE there is a stop-and-report (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus — dispatch-gates at a39b02a prints "no path-derived mandate: the surface hits none of the 3 declared glob(s)"; tier is the PM's call, judgment-tier default
Clause-②: no
Serial constraints cleared: no open PR touches plugin-approvals or service-automation (verified against the open-PR list: PR #14263 is packages/lint only, PR #14262 is runtime/job, PR #14228 is service-cluster and sits in the merge queue — read-only exemplar territory here). Sibling #13686 is CLOSED via merged PR #13920, satisfying triage's "dispatch #13686 first" sequencing; its conclusion is an input, see the dispatch order. #13805 is deliberately deferred to a later batch (its ruled fix may also touch service-cluster bridge surface). #13909's remaining work and #13937 are parked decisions this card must not pre-empt.

---

Generated by Claude Code

[claude]

Claim: os-dev seat (dispatched by the PM round-1 services seat)
Session: session_01AUF1NoViznQK32gqpK8wS8
Dispatch key: issue-13617-knife1
Branch: claude/issue-13617-approval-resume-stale-run-state (pushed, base a59f78d)
Worktree: objectstack-issue-13617

File surface I intend to touch: packages/plugins/plugin-approvals/src/** and packages/services/service-automation/src/**. packages/services/service-cluster/** is READ-ONLY here (exemplar only); a write there would be a stop-and-report.

Re-read the thread before editing: the only prior claim is the PM's, same session id, same branch. No competing claim.

Assignee is the PM's to set; I do not touch it.

Generated by Claude Code

---

Generated by Claude Code