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]>
34 行
2.3 KiB
Markdown
34 行
2.3 KiB
Markdown
# 采购提交事务负载下超时返回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
|
||
|
||
- [x] 三处事务传入 `{ maxWait: 5000, timeout: 10000 }`，采购与报销提交各有回归断言（去掉修复即失败）。
|
||
- [x] 后端全量单测通过（4451 / 1 原跳过）。
|
||
- [x] 负载复现不再出现采购提交 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）。
|