lzh
4d85659277
fix(ops): 修复同一工牌并行多单的状态错乱
线上观察:管理员手动取消一个僵尸 DISPATCHED 单会引发"越清越多"——
系统顺势派队列首条给仍在工作的保洁员,监听器再用"旧工单残留"机制
尝试取消当前正在执行的工单,该取消走 REQUIRES_NEW 独立事务且吞异常,
最终新单落地、旧单残留,同一设备挂多个非终态工单。
修复两处:
1. DispatchEngineImpl.autoDispatchNext 入口加设备空闲校验:
若执行人名下还有 DISPATCHED/CONFIRMED/ARRIVED/PAUSED 工单(排除
completedOrderId),直接早返回,不再派发。所有调用方(保洁/安保
handleCancelled、asyncCompleteAndDispatchNext、xxl-job 空闲扫描)
自动受保护。新增 OpsOrderMapper.selectActiveByAssignee。
2. BadgeDeviceStatusEventListener.handleDispatched 移除"残留取消":
旧逻辑用 REQUIRES_NEW 事务 + 吞异常,是对数据已错乱场景的暴力兜底,
失败时导致误杀。改为只打 ERROR 告警暴露问题,仅清理 Redis 关联。
真正的防线在 DispatchEngine 入口。
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-20 10:54:54 +08:00
..
2026-04-20 10:54:54 +08:00
2025-12-31 16:49:44 +08:00
2026-04-13 23:18:30 +08:00
2026-04-20 10:54:54 +08:00
2026-04-05 15:26:43 +08:00
2026-03-27 16:37:30 +08:00
2025-12-31 16:49:44 +08:00
2025-12-31 16:49:44 +08:00