wangsli和Claude Opus 5.5
0931b1ea49
app-api-runtime 对 /api/me、/api/workflow/tasks*、/api/workflow/approvers*、 /api/notifications* 使用 NetworkFirst + networkTimeoutSeconds: 3。网络响应 超过 3 秒时 Service Worker 返回审批前缓存的旧响应，真实响应被丢弃，页面 仍显示「待派发」。审批写入本身正确。自 2026-03（9112383d）起存在。 去掉网络超时，只在网络失败（离线）时回退缓存；退出登录清理缓存不变。 新增回归测试锁定该规则。负载复现修复前 3 轮命中 2 轮，修复后 3 轮 0 命中。 Co-Authored-By: Claude Opus 5.5 <[email protected]>
2.8 KiB
2.8 KiB
2026-09-26 根因确认与修复（当前）
- 带诊断复现命中（CG-20260926-0006，任务 48d14805）：浏览器 01.973 发 GET，05.049 收到 pending；服务端 02.255 收到同一 GET，05.598 才读库且读到 completed。浏览器拿到的响应早于服务端读库，来源只能是 Service Worker 缓存。
- 根因：
client/vite.config.ts的app-api-runtime规则对/api/me、/api/workflow/tasks*、/api/workflow/approvers*、/api/notifications*用NetworkFirst+networkTimeoutSeconds: 3；网络响应超过 3 秒时 SW 返回审批前缓存的旧响应，真实响应被丢弃。自 2026-03 P21PWA2（9112383d）起存在，生产同样受影响（慢网络/企微手机下审批后页面显示未通过，再点报「已处理」，待办列表可能显示已处理单据）。审批写入本身从未丢失。 - 修复：去掉
networkTimeoutSeconds，仅网络失败（离线）才回退缓存；退出登录清理该缓存（client/src/pwa.ts:201）不变。新增server/tests/unit/utils/client-pwa-api-cache.test.js（有修复通过、去掉修复失败）；构建产物dist/sw.js已无超时。 - 修复后复现脚本 3 轮验证（修复前 3 轮命中 2 轮）。
- 通过后
verify-candidate取得 PASS 回执。 - 后续另议：
/api/workflow/tasks*含报销审批内容仍会被 SW 缓存供离线读取，与「报销审批证据不进入离线缓存」口径是否冲突待确认；采购提交事务 P2028 见下方。
2026-09-26 调查进度
- 非 managed 复现环境：
research/repro.sh（需先sed抽取 run-web-gates.sh 1–929 行并删 9–17 行为 gates-lib.sh；库前缀须hyb_oa_webgate_；直接调用prepareAccounts）。采购 ×6 + permission-direct-access ×6，4 worker，约 13 分钟。 - 第 1 轮复现命中：CG-20260926-0006 页面停在「待派发」、历史仅「提交」；保留库中该单 approved、任务 completed/approved、历史 start,approve。结论：审批写入未丢失，问题在审批后页面刷新拿到/显示旧状态。时序：approve 06.418→09.868(200)，task completed_at 07.948，页面 GET 10.289→13.099(200)。
- 第 2 轮加服务端 DIAG 读日志 + 浏览器响应监听（
research/diag-instrumentation.patch，未提交，已从工作区还原）：未复现；22 次成功审批后的 27 次读取无 pending。 - 带诊断多跑几轮直至命中，确定旧状态来自服务端响应还是前端未应用。
- 另行处理：负载下采购提交事务超过 Prisma 默认 5000ms 交互事务超时（P2028→500，
server/src/routes/purchaseRequests.js:1704，两轮各 1–2 次）。生产b1d25d3c同写法，非本次回归。 - 顺带出现的其他随机失败：permission-direct-access AP6（待办汇总计数）/PA6（VALID_001），负载相关，未分析。