重现步骤
历史记录
- 2022-10-27 16:09:12, 由 农基望 创建。
-
2022-10-31 09:30:56, 由 程伟 指派给 李振宇。
修改了 指派给，旧值为 "chengwei"，新值为 "lizhenyu"。
-
2022-10-31 15:58:26, 由 李振宇 添加备注。
优化方案：将以前控制服务并发的key（环境变量 + InsertShipmentOrderToLogisticsJob）修改为环境变量 + 客户编号 + 中转单号（按照订单维度控制并发）
-
2022-10-31 15:58:35, 由 李振宇 指派给 程伟。
修改了 指派给，旧值为 "lizhenyu"，新值为 "chengwei"。
-
2022-10-31 15:59:41, 由 程伟 确认Bug。
修改了 是否确认，旧值为 "0"，新值为 "1"。
-
2022-10-31 16:02:50, 由 程伟 解决，方案为 第三方原因（外部系统） 。
修改了 解决方案，旧值为 ""，新值为 "external"。
修改了 解决版本，旧值为 ""，新值为 "trunk"。
修改了 解决日期，旧值为 ""，新值为 "2022-10-31 15:59:43"。
修改了 指派给 ，旧值为 "chengwei"，新值为 "nongjiwang"。
修改了 Bug状态 ，旧值为 "active"，新值为 "resolved"。
修改了 解决者 ，旧值为 ""，新值为 "chengwei"。
问题原因：
系统重复预生成之后，会将重复的追踪号记录到数据库，并且自动调用取消追踪号接口，但是TOM物流并没有提供一订单多多箱的取消追踪号接口。
所以系统只是提供了一个导出重复追踪号功能，让客户自己导出重复的追踪号之后，去物流商后台取消
我们只是做了一部分简单的防错机制，就是通过Redis分布式并发锁去尽可能避免服务并发导致的追踪号重复获取。
-
2022-11-08 09:06:13, 由 农基望 关闭。
修改了 Bug状态 ，旧值为 "resolved"，新值为 "closed"。
修改了 指派给 ，旧值为 "nongjiwang"，新值为 "closed"。
修改了 由谁关闭，旧值为 ""，新值为 "nongjiwang"。
修改了 关闭日期，旧值为 ""，新值为 "2022-11-08 09:06:13"。
并发测试验证通过
| 所属项目 | 技术中心-需求池 |
|---|---|
| 所属模块 | / |
| 所属迭代 | 技术研发中心 10月分支版本（2022年） |
| Bug类型 | 第三方原因(外部系统) |
| 严重程度 | 提示 |
| 优先级 | P2 |
| Bug状态 | 已关闭 |
| 业务部门 | |
| 开发责任人 | |
| 测试责任人 | |
| 解决时效 | 0 |
| 激活次数 | 0 |
| 激活日期 | |
| 当前指派 | Closed 于 2022-11-08 09:06:13 |
| 截止日期 | 0000-00-00 |
| 上线时间 | |
| 上线时效 | |
| 关键词 | |
| 抄送给 |
| 所属迭代 | 技术研发中心 10月分支版本（2022年） |
|---|---|
| 相关需求 | |
| 相关任务 |
| 由谁创建 | 农基望 于 2022-10-27 16:09:12 |
|---|---|
| 影响环境 |
629 |
| 由谁解决 | 程伟 于 2022-10-31 15:59:43 |
| 解决版本 | 主干 |
| 解决方案 | 第三方原因（外部系统） |
| 由谁关闭 | 农基望 于 2022-11-08 09:06:13 |
| 最后修改 | 农基望 于 2022-11-08 09:06:13 |
| 相关Bug |
|---|