wangsli和Claude Opus 5.5
b6f0c83608
负载下采购提交事务超过 Prisma 交互事务默认 5000ms（P2028）返回 500。
分段计时显示无单一瓶颈（总时长中位 843ms、最大 3506ms，编号锁等待
最多 535ms），是约 20 条顺序查询整体变慢贴近上限。报销新建/提交同结构。
三处改用项目既有的 { maxWait: 5000, timeout: 10000 }，事务内容不变；
新增采购与报销提交的事务选项回归断言。
Co-Authored-By: Claude Opus 5.5 <[email protected]>
2.2 KiB
2.2 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 }，采购与报销提交各有回归断言（去掉修复即失败）。 - 后端全量单测通过。
- 负载复现不再出现采购提交 P2028。
Test Plan
server/tests/unit/routes/purchase.submit-budget-precheck.test.js：新增断言提交事务选项；已验证去掉修复时该用例失败。server/tests/unit/routes/reimbursements.expense-standards.test.js：在既有成功提交用例中断言事务选项。- 后端全量 vitest；负载复现脚本（见 09-26-approve-success-state-unchanged/research/repro.sh）。