1.8 KiB
1.8 KiB
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 备份恢复