27 lines
1.8 KiB
Markdown
27 lines
1.8 KiB
Markdown
# 2026-08-11 操作日志
|
||
|
||
## 修复确认下单重复生成订单
|
||
- **问题**：国内订单管理出现完全一样的重复订单（如 POZ-TMG-8620 在 7-24 15:26:12 和 15:26:16 各生成一条，仅差 4 秒）
|
||
- **定位**：确认下单接口无防重复机制，双击/快速重复点击时多个请求同时通过"待下单状态"检查，各自生成订单
|
||
- **修复**：
|
||
- 后端 `confirm_order` 增加原子抢占（`UPDATE pending_orders SET status='ordered' WHERE status='pending'` 检查受影响行数），只有抢占成功的请求才生成订单
|
||
- 前端确认下单按钮加 `_pendingConfirmLock` 防重复提交锁
|
||
- services/db.py 新增 `execute()` 返回受影响行数
|
||
- **验证**：3 线程并发测试，仅 1 个请求成功（结果 [1,0,0]）
|
||
- **提交**：2304696，已重启测试服务（18888）
|
||
|
||
## 确认下单备份覆盖逻辑
|
||
- **确认**：下单备份管理按货品编号唯一保存（pending_orders.product_code 唯一约束），同一商品多次下单会覆盖旧的下单时间/BOM 等备份数据
|
||
- **状态**：已向旭东确认是否需要改为保留多次下单历史，待回复
|
||
|
||
## 下单备份管理支持多次下单历史
|
||
- **需求**：下单备份管理保留多次下单历史，每次确认下单新增一条备份记录
|
||
- **改动**：
|
||
- 删除 pending_orders 的 uk_product_code 唯一约束（ALTER TABLE DROP INDEX）
|
||
- confirm_order 按 id 原子抢占，每次确认产生独立 ordered 备份行
|
||
- 回退/生产单号/包材单号等操作按 backup_id 精确定位，仅影响目标批次
|
||
- 待下单编辑/删除/保存BOM限定 status='pending'，不碰历史行
|
||
- **验证**：全链路 HTTP 测试（两次下单2条历史+回退保留1条）、并发抢占测试
|
||
- **提交**：7de9eb1，已重启测试环境
|
||
- **注意**：测试登录曾改汤定毅密码，已从 7/31 备份恢复
|