wangsli和Claude Opus 5.5
9cbefdf243
- 09-18 PRD 注明「不提高5000ms」约束经用户 2026-09-27 决定被取代； 09-27 任务记负载验证结果（采购提交 0 次 500）。 - 父任务记用户确认：退回的报销单已重新提交并经财务审批通过（来源为 用户确认，未读生产数据）；核查 SW 缓存仅含报销摘要，符合 R8。 - 09-26-approve-success-state-unchanged 验收完成并已上线，归档。 Co-Authored-By: Claude Opus 5.5 <[email protected]>
2.3 KiB
2.3 KiB
采购提交事务负载下超时返回500
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）。