wangsli和Claude Opus 5.5
b85ff6a9bf
- 报销一页式审批工作台父任务及 B-2a/B-2b/只读一致性子任务（AC11 依用户 2026-09-27 确认）
- 报销详情材料预览修复及其部署子任务（由候选 59dc5f6 发布覆盖，原步骤未执行，记录保留）
- 资产事前批准纠偏、Trellis 流程对齐、ERP 遗留精简、预算池并发、采购提交超时
- 各任务 prd 顶部新增收口记录，实现均包含于生产 4a5cd8f2；原未勾清单保留不补勾
- B 组与有真实待办的任务保持进行中
Co-Authored-By: Claude Opus 5.5 <[email protected]>
2.7 KiB
2.7 KiB
采购提交事务负载下超时返回500
2026-10-11 收口归档
任务元数据曾停留在 planning，实际实施 b6f0c836（采购提交与报销新建/提交事务显式 10 秒上限，记录 9cbefdf2）已上线，包含于当前生产 4a5cd8f2；唯一未勾项“随下次发布上线”已满足。原未勾选清单为当时规划记录，保留原样、不补勾。经用户 2026-10-11 明确授权归档。
Goal
消除采购提交（及同结构的报销新建/提交）在负载下超过 Prisma 交互事务默认 5000ms 上限而返回 500（P2028）的问题。
Background / Evidence（2026-09-26/27）
- 09-26 负载复现（采购 ×6–8 + permission-direct-access ×6–8，4 worker，2 核主机）每轮出现 1–2 次
purchase submit failed: 500，服务端为P2028 Transaction API error ... timeout 5000 ms, 5352 ms passed，位于server/src/routes/purchaseRequests.js提交事务内的workflowTask.create。正式门禁 6 轮未出现。 - 生产
b1d25d3c与当前代码同写法（默认超时），非近期回归。 - 09-27 事务内分段计时（16 次提交全部成功）：锁定单据中位 41/最大 290ms；编号前校验与预检 466/1659ms；编号分配含锁等待 101/535ms；编号后至提交 317/2194ms；事务总时长中位 843ms、最大 3506ms。无单一瓶颈：编号行锁等待最多 0.5s，主要是约 20 条顺序查询在负载下整体变慢，贴近 5s 上限。
- 报销新建（
POST /reimbursements）与提交（/reimbursements/:id/submit）同样在默认超时事务内分配编号、执行多步写入，属同一风险。
Scope
- 采购提交、报销新建、报销提交三处交互事务显式使用项目既有写法
{ maxWait: 5000, timeout: 10000 }（付款批次、回执 OCR 等已采用）。 - 不改事务内容、顺序、锁、编号或业务语义。
Out of Scope
缩短编号行持锁时间的重排、其他路由事务的统一治理、部署。
Acceptance Criteria
- 三处事务传入
{ maxWait: 5000, timeout: 10000 }，采购与报销提交各有回归断言（去掉修复即失败）。 - 后端全量单测通过（4451 / 1 原跳过）。
- 负载复现不再出现采购提交 P2028（2 轮 0 次，修复前每轮 1–2 次）。
Test Plan
server/tests/unit/routes/purchase.submit-budget-precheck.test.js：新增断言提交事务选项；已验证去掉修复时该用例失败。server/tests/unit/routes/reimbursements.expense-standards.test.js：在既有成功提交用例中断言事务选项。- 后端全量 vitest；负载复现脚本（见 archive/2026-09/09-26-approve-success-state-unchanged/research/repro.sh）。