lunanting/cangku
1
0
Fork 1
Code Issues Pull Requests 2 Actions Packages Projects Releases Wiki Activity

fix(wst): 起算点改为「审核时间 / 订单 modified 取较晚者」，修 13:00 轮 65 单假超时 #91

Merged
yanhui merged 1 commits from yanhui-wst-modified-1028 into main 2026-10-28 17:07:11 +08:00
Conversation 0 Commits 1 Files Changed 3 +135 -34
yanhui commented 2026-10-28 17:03:53 +08:00
Collaborator
Copy Link

目的与范围

修 13:00 轮「65 单假超时」。业务举证：9 点前的单 13:00 前已经发完了，不该还有。逐单核对确认全部不该在 13:00 轮。

范围：warehouseShipTimelinessService.js 起算点口径 + 状态表查询并发化 + 前端说明文案 + 2 个新测试。不改轮次窗口、不改快递剔除规则、不改已发判定。

根因（两个，都指向起算点取错）

① 状态表审核时间严重滞后

业务举证单 9978643：

字段 值
qmcust.modified 2026-10-28 14:52:29
聚水潭页面真实审核时间 2026-10-28 14:52:28（秒级吻合）
状态表 last_oa_confirm_time 2026-10-27 17:08:43（旧了一天）
状态表 query_time 2026-10-28 10:29:11（10:29 后没再抓）

只信状态表 → 这单被当成「10-27 就审核了」，混进 13:00 轮，冤枉仓库。

② 审核时间为空的单回退 created，把今天的单按历史单算

65 单里 57 单状态表审核时间为 NULL，回退 created 后：

o_id created modified 回退后 真实
9964841 10-26 17:22 10-28 13:40 算 10-26 审核 → 进 13:00 轮 今天下午才审核
9949424 10-25 17:03 10-28 13:50 同上 同上
9983773 10-27 23:23 10-28 13:59 同上 同上

57 单的 modified 全部落在今天 13:40~15:03，都是今天下午批量审核的。

改动

  1. 起算点 = max(状态表 last_oa_confirm_time, 订单表 modified, 订单表 created)
    • 取较晚者 → 修状态表滞后
    • 纳入 created → 个别单 modified 早于 created（脏数据），起算点不该早于下单时刻
    • benchmarkSource 透出 oa_confirm / modified / created
  2. 新增 laterOf()：同格式 YYYY-MM-DD HH:mm:ss 字典序比较，不转 Date（避开时区坑）
  3. 主查询 SQL 增加 x.modified（订单两表都有，无额外查询）
  4. 状态表查询改并发 6（见下）

性能（同批修复，线上曾 300s 超时）

上版状态表查询串行 9 批实测 135s，叠加主查询 63~105s 把 /list 顶过 300s，页面打不开（实测 curl --max-time 300 超时）。

方式 耗时
串行 9 批 135s
并发 3 28.8s
并发 6（本版） 10~15s

同步与兼容性

  • 接口字段只增不改：orders[].benchmarkSource 新增取值 modified，前端已适配（只有 created 才打 *）
  • 导出 Excel/CSV 列不变
  • 钉钉推送文案不变
  • 无数据库结构变更、无配置变更

验证

  • 后端 npm run check：493/495（2 个失败是既有环境问题：TTL 计时、Windows 权限，改动前同样失败）
  • 新增 2 个测试锁定口径：
    • modified 晚于窗口 → 必须剔除（9978643 那类单）
    • 状态表审核时间晚于 modified → 以状态表为准
    • modified 早于 created → 取 created，不倒退
  • 前端 lint + build 通过（35.2s）
  • 真实库双轮验证：
轮次 改前 改后
13:00 轮 65 单 0 单
18:00 轮 — 927 单（全部今天 07:59~16:00 审核，无历史单）
  • fallbackToCreated 57 → 0
  • 9978643 ✅ 剔除
  • 两轮都验证「今天窗口上界之后起算的 = 0」

风险与回退

  • modified 被客服改单/改备注刷新时起算点会推后 → 少报超时（放行方向，不冤枉仓库）。业务已知悉。
  • 回退：git revert <merge commit> 即回到只认状态表审核时间的版本。
## 目的与范围 修 13:00 轮「65 单假超时」。业务举证：**9 点前的单 13:00 前已经发完了，不该还有**。逐单核对确认全部不该在 13:00 轮。 范围：`warehouseShipTimelinessService.js` 起算点口径 + 状态表查询并发化 + 前端说明文案 + 2 个新测试。不改轮次窗口、不改快递剔除规则、不改已发判定。 ## 根因（两个，都指向起算点取错） ### ① 状态表审核时间严重滞后 业务举证单 **9978643**： | 字段 | 值 | |---|---| | `qmcust.modified` | **2026-10-28 14:52:29** | | 聚水潭页面真实审核时间 | **2026-10-28 14:52:28**（秒级吻合） | | 状态表 `last_oa_confirm_time` | 2026-10-27 17:08:43（旧了一天） | | 状态表 `query_time` | 2026-10-28 10:29:11（10:29 后没再抓） | 只信状态表 → 这单被当成「10-27 就审核了」，混进 13:00 轮，冤枉仓库。 ### ② 审核时间为空的单回退 created，把今天的单按历史单算 65 单里 **57 单**状态表审核时间为 NULL，回退 `created` 后： | o_id | created | modified | 回退后 | 真实 | |---|---|---|---|---| | 9964841 | 10-26 17:22 | **10-28 13:40** | 算 10-26 审核 → 进 13:00 轮 | 今天下午才审核 | | 9949424 | 10-25 17:03 | **10-28 13:50** | 同上 | 同上 | | 9983773 | 10-27 23:23 | **10-28 13:59** | 同上 | 同上 | 57 单的 `modified` **全部落在今天 13:40~15:03**，都是今天下午批量审核的。 ## 改动 1. **起算点** = `max(状态表 last_oa_confirm_time, 订单表 modified, 订单表 created)` - 取较晚者 → 修状态表滞后 - 纳入 created → 个别单 `modified` 早于 `created`（脏数据），起算点不该早于下单时刻 - `benchmarkSource` 透出 `oa_confirm` / `modified` / `created` 2. **新增 `laterOf()`**：同格式 `YYYY-MM-DD HH:mm:ss` 字典序比较，不转 Date（避开时区坑） 3. **主查询 SQL 增加 `x.modified`**（订单两表都有，无额外查询） 4. **状态表查询改并发 6**（见下） ## 性能（同批修复，线上曾 300s 超时） 上版状态表查询**串行 9 批实测 135s**，叠加主查询 63~105s 把 `/list` 顶过 300s，**页面打不开**（实测 `curl --max-time 300` 超时）。 | 方式 | 耗时 | |---|---| | 串行 9 批 | 135s | | 并发 3 | 28.8s | | **并发 6（本版）** | **10~15s** | ## 同步与兼容性 - 接口字段只增不改：`orders[].benchmarkSource` 新增取值 `modified`，前端已适配（只有 `created` 才打 `*`） - 导出 Excel/CSV 列不变 - 钉钉推送文案不变 - 无数据库结构变更、无配置变更 ## 验证 - 后端 `npm run check`：**493/495**（2 个失败是既有环境问题：TTL 计时、Windows 权限，改动前同样失败） - 新增 2 个测试锁定口径： - `modified` 晚于窗口 → 必须剔除（9978643 那类单） - 状态表审核时间晚于 `modified` → 以状态表为准 - `modified` 早于 `created` → 取 `created`，不倒退 - 前端 lint + build 通过（35.2s） - **真实库双轮验证**： | 轮次 | 改前 | 改后 | |---|---|---| | 13:00 轮 | 65 单 | **0 单** | | 18:00 轮 | — | 927 单（全部今天 07:59~16:00 审核，无历史单） | - `fallbackToCreated` 57 → **0** - 9978643 ✅ 剔除 - 两轮都验证「今天窗口上界之后起算的 = 0」 ## 风险与回退 - **`modified` 被客服改单/改备注刷新**时起算点会推后 → 少报超时（放行方向，不冤枉仓库）。业务已知悉。 - 回退：`git revert <merge commit>` 即回到只认状态表审核时间的版本。
yanhui added 1 commit 2026-10-28 17:03:53 +08:00 
## 业务问题

业务举证：13:00 轮不该有那么多单 —— 「9 点前的单 13:00 前已经发完了」。
线上实测 65 单，逐单核对全部不该在 13:00 轮。

## 根因（两个，都指向「起算点取错」）

### ① 状态表的审核时间会严重滞后

业务给的举证单 9978643：

| 字段 | 值 |
|---|---|
| `qmcust.modified` | **2026-10-28 14:52:29** |
| 聚水潭页面真实审核时间 | **2026-10-28 14:52:28**（秒级吻合） |
| 状态表 `last_oa_confirm_time` | 2026-10-27 17:08:43（旧了一天） |
| 状态表 `query_time` | 2026-10-28 10:29:11（10:29 后没再抓） |

只信状态表 → 这单被当成「10-27 就审核了」，混进 13:00 轮超时，冤枉仓库。

### ② 审核时间为空的单回退 created，把今天的单按历史单算

65 单里 57 单状态表审核时间为 NULL。回退 `created` 后：

| o_id | created | modified | 回退后算成 | 真实 |
|---|---|---|---|---|
| 9964841 | 10-26 17:22 | **10-28 13:40** | 10-26 审核 → 进 13:00 轮 | 今天下午才审核 |
| 9949424 | 10-25 17:03 | **10-28 13:50** | 同上 | 同上 |
| 9983773 | 10-27 23:23 | **10-28 13:59** | 同上 | 同上 |

57 单的 `modified` 全部落在今天 13:40~15:03 —— 都是今天下午批量审核的。

## 改动

- **起算点** = `max(状态表 last_oa_confirm_time, 订单表 modified, 订单表 created)`
  - 取较晚者：修状态表滞后
  - 纳入 created：个别单 `modified` 早于 `created`（脏数据），起算点不该早于下单时刻
  - `benchmarkSource` 透出 `oa_confirm` / `modified` / `created`，页面 tooltip 说明来源
- **新增 `laterOf()`**：同格式 `YYYY-MM-DD HH:mm:ss` 直接字典序比较，不转 Date（避开时区坑）
- **主查询 SQL 增加 `x.modified`** 列（订单两表都有，无需额外查询）

## 性能修复（同批，线上 /list 曾 300s 超时）

上版状态表查询**串行 9 批实测 135s**，叠加主查询 63~105s 直接把接口顶过 300s，
页面打不开（实测 curl `--max-time 300` 超时）。改为**并发 6**：

| 方式 | 耗时 |
|---|---|
| 串行 9 批 | 135s |
| 并发 3 | 28.8s |
| **并发 6（本版）** | **10~15s** |

并发 6 是生产实测的安全值（单批约 15s，不至于把 402 万行视图的连接池打爆）。

## 改后效果（10-28 17:00 真实库）

| 轮次 | 改前 | 改后 |
|---|---|---|
| 13:00 轮 | 65 单 | **0 单** |
| 18:00 轮 | — | 927 单（全部今天 07:59~16:00 审核，无历史单） |

- `fallbackToCreated` 从 57 → **0**（不再有回退单）
- 9978643 ✅ 已剔除
- 两个轮次都验证「今天窗口上界之后起算的 = 0」

## 验证

- 后端 `npm run check`：**493/495**（2 个失败是既有环境问题：TTL 计时、Windows 权限，改动前同样失败）
- 新增 2 个测试锁定该口径：
  - `modified` 晚于窗口 → 必须剔除（9978643 那类单）
  - 状态表审核时间晚于 `modified` → 以状态表为准
  - `modified` 早于 `created` → 取 `created`，不倒退
- 前端 lint + build 通过（35.2s）
- 真实库双轮验证通过

## 风险与回退

- **`modified` 被客服改单/改备注刷新**时起算点会推后 → 少报超时（放行方向，不冤枉仓库）。
  业务已知悉并接受；这是当前唯一能拿到「今天真实审核时间」的可靠字段。
- 回退方式：`git revert <merge commit>` 即回到只认状态表审核时间的版本。
yanhui merged commit 6b6dfdd1da into main 2026-10-28 17:07:11 +08:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
wangjie Xkh5201314 yanhui youruo lunanting
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: lunanting/cangku#91
No description provided.
Delete Branch "yanhui-wst-modified-1028"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?