|
|
50a826f157
|
docs(video): WVP-Platform 迁移提案 (proposal + tasks + design)
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-21 10:15:02 +08:00 |
|
|
|
948d2c6a41
|
feat(video): 新建 viewsh-module-video 服务模块骨架
新增视频管理模块，用于后续迁移 WVP-Platform（GB28181 视频监控平台）。
- viewsh-module-video-api: 契约层（Feign RPC 接口、枚举、错误码）
- viewsh-module-video-server: 业务层（端口 48093）
- 网关路由: video-admin-api / video-app-api
- SecurityConfiguration: 放行 Swagger/Actuator/Druid/RPC
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-21 10:15:02 +08:00 |
|
|
|
65ad3f35e5
|
Merge branch 'master' into feat/multi-tenant
吸收 master 今日 9 个工单链路修复：
- autoDispatchNext/dispatch 空闲兜底 + FOR UPDATE 并发防护
- 状态转换审计闭环（AFTER_COMMIT/AFTER_ROLLBACK）
- 队列楼层权重强优先 + 三级 baseline 兜底 + N+1 优化
- 工牌 nickname 回填
- CleanOrderAutoCancelJob 超时工单自动取消
|
2026-04-20 16:04:46 +08:00 |
|
|
|
c78759fd52
|
feat(ops): 新增保洁工单超时自动取消 Job + 集成测试
Java CI with Maven / build (11) (push) Has been cancelled
Java CI with Maven / build (17) (push) Has been cancelled
Java CI with Maven / build (8) (push) Has been cancelled
背景：保洁工单偶尔因设备离线/信标丢失导致卡在非终态（如 PENDING 超 12h 没派，
DISPATCHED 超 12h 没确认），靠人工清理成本高。补一个每小时跑的 XXL-Job 扫描关单。
实现：
- CleanOrderAutoCancelJob.scanAndCancel：
* 查询 update_time 距今超 timeoutHours（默认 12h）的 CLEAN 工单
* 状态白名单 = PENDING/QUEUED/DISPATCHED/CONFIRMED/ARRIVED，**排除 PAUSED**
（PAUSED 是 P0 打断的产物，应由 resumeInterruptedOrder 走状态机恢复，
此处若把它 CANCEL，会破坏 P0 完成后的 resume 链路）
* 调用 orderLifecycleManager.cancelOrder 走完整责任链，事件监听器负责
TTS 停播/设备关联回收/审计日志
* cancel 前再 selectById 做乐观校验：若 update_time 已刷新或状态已变
（COMPLETED/CANCELLED/PAUSED），跳过；避免候选装内存到实际 cancel
之间用户刚触达的工单被误杀
* 单单独立 try/catch 隔离，单条失败不断批
* batchSize 限流（默认 200），事件风暴防护
- application.yaml 补默认配置：viewsh.ops.clean.auto-cancel.{timeout-hours, batch-size}
- CleanOrderAutoCancelJobTest 覆盖 6 条不变量：
无候选零计数、全成功、部分失败不中断、乐观锁跳过 stale、终态跳过、PAUSED 跳过
XXL-Job 配置建议：
- JobHandler: cleanOrderAutoCancelJob
- Cron: 0 17 * * * ? （每小时 :17，避开整点尖峰）
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
2026-04-20 15:21:33 +08:00 |
|
|
|
ba6f94a279
|
fix(ops): review 复盘补齐 FOR UPDATE 覆盖面 + 清理注解/日志死角
今日 review 发现 Bug #2 的 FOR UPDATE 防线只装在 dispatch() 上，但同文件另有两条
路径绕过它：
1. P1 — DispatchEngineImpl.autoDispatchNext 调 transition() 派发队列下一单，
不走 FOR UPDATE。idle 校验和 transition 之间存在竞争窗口，能再次让同 assignee
挂两条 DISPATCHED。改调 dispatch()，天然继承串行化。
补测 autoDispatchNext_whenDispatchingFromQueue_shouldGoThroughDispatchNotTransition
锁定该不变量。
2. P2 — OrderLifecycleManagerImpl.resumeOrder/resumeInterruptedOrder 同样走
transition()，P0 恢复与并发派发竞争时可能产生两条 DISPATCHED。改为先
selectById 取 assigneeId，改调 dispatch() 让同一检查生效。
顺手清理 3 个误导：
- DispatchEngineImpl.executePushAndEnqueue 原先忽略内部 dispatch 的返回值，
并发场景下会输出假的“已推送等待任务”日志误导运维，改为按 result.isSuccess()
分支打印。
- OrderTransitionAuditListener.writeRollbackAudit 的 @Transactional(REQUIRES_NEW)
是死注解（由 onAfterRollback 自调用，Spring 代理无法拦截；且 AFTER_ROLLBACK
本就无事务），移除并更新 Javadoc 说明实际行为。
- OrderQueueServiceEnhanced.triggerQueueRebuildAfterCommit 的自调用绕过
@Transactional 是设计意图（最终一致即可），补 Javadoc 解释事务边界，
避免后续误判为 bug。
测试：ops-biz 56 个相关用例全部通过，含新增的 P1 锁定测试。
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
2026-04-20 14:51:32 +08:00 |
|
|
|
9f3ca9c6f2
|
test(ops): 补齐工单链路 5 个修复点的集成测试
与 4d85659…a5f916c 的 5 次修复对齐，用 Mockito 风格覆盖状态链路关键分支：
- DispatchEngineIdleCheckTest：autoDispatchNext 空闲兜底 + executeDispatch
MySQL 活跃态降级（Bug #1/#4），ENQUEUE_ONLY 路径不触发兜底查询避免开销浪费
- DispatchEngineConflictFallbackTest：FOR UPDATE 冲突分支（Bug #2），
PENDING → 降级入队、QUEUED → 保持排队、其他错误码 → 硬失败
- OrderTransitionAuditListenerTest：审计闭环（Bug #7），AFTER_COMMIT 成功/WARN/ERROR
分支 + AFTER_ROLLBACK 强制视为失败 + 7 种目标状态映射
- QueueScoreCalculatorEnhancedTest：楼层权重 G+B，锁死"FLOOR×10 > AGING×240"
不变量，验证 base/target 任一 null → score=0，移除旧 +600 罚分后语义对称
22 个新测试全部通过；模块内 115/117 测试通过，2 个 pre-existing 失败
(VspNotifyClient/AreaDeviceRelation) 依赖外部服务，与本次改动无关。
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
2026-04-20 14:24:07 +08:00 |
|
|
|
323ddf27fb
|
fix(ops): 对账回填工牌 nickname，修复重启后派单人名降级为 deviceCode
根因：BadgeDeviceStatusSyncJob 硬编码 nickname=null，依赖 Redis 已有值。
重启后若 ops:badge:device:{deviceId} 的 nickname 丢失（TTL/清理/首次写入），
BadgeDeviceAreaAssignStrategy 会降级用 deviceCode，导致 assigneeName 变成 "43607737587"。
- SyncJob 注入 IotDeviceQueryApi，批量拉 IotDeviceSimpleRespDTO.nickname 做回填
- 状态一致但 Redis 缺 nickname 时也补写一次，覆盖最常见的重启路径
- AreaAssignStrategy 降级兜底改为 "工牌-尾号"，避免再把裸 deviceCode 当人名暴露
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
2026-04-20 13:50:00 +08:00 |
|
|
|
a5f916c62a
|
fix(ops): 队列楼层权重修复——强楼层优先 + 闭环基准兜底 + N+1 优化
问题：楼层差在分数公式中本该主导同优先级排序，但有四个缺陷导致效果不稳：
1. 有 base 无 target 时给 +600 罚分，无 base 时则全免罚——同一工单在
保洁员忙/闲时排序不单调（B）。
2. 基准楼层只在 user 有 PROCESSING 时生效，空闲时完全无楼层信号（A）。
3. enqueue 瞬间 score 不含楼层，要等下一轮 rebuild 才补上（H）。
4. aging 上限 720 > floorDiff 上限 600，等满 4 小时可反超同优先级 10 层差
任务，削弱"强楼层优先"语义（G）。
5. rebuild 内 for 循环对每条 WAITING 单独 selectById(order)+selectById(area)，
N+1 问题（F）。
修复：
1. QueueScoreCalculator（B + G）
- FLOOR_WEIGHT 60 → 100：上限 1000 > aging 上限 720，4 小时老化不再反超
同优先级的近楼层任务。
- 删除"有 base 无 target +600"分支：任一侧缺失即 score=0，语义对称。
2. OpsOrderMapper.selectLatestCompletedAreaIdByAssignee（A 二级兜底）
查最近 24h 内已完成工单的 area，用来推断空闲保洁员的物理位置。
超过 24h 视为跨班次、轨迹失效。
3. OrderQueueServiceEnhanced.resolveBaselineAreaId（A 三级兜底）
PROCESSING.area → 最近 24h COMPLETED.area → 调用方传的 fallbackAreaId。
4. OrderQueueServiceEnhanced.enqueue（H）
事务提交后 triggerQueueRebuildAfterCommit(userId, null)，新入队工单
立即按楼层差参与排序，不依赖下一次 autoDispatchNext 触发。
5. OrderQueueServiceEnhanced.rebuildWaitingTasksByUserId（F）
批量 selectBatchIds(orders) + selectBatchIds(areas)，100 条 WAITING
从 200 次 SELECT 降到 2 次。
权重直观对比（P2=priority×1500=3000）：
旧分数 新分数
同层刚入队 3000 3000
差5层刚入队 3000+300=3300 3000+500=3500
差5层等2小时 3000+300-360=2940 3000+500-360=3140
同层等4小时 3000+0-720=2280 3000+0-720=2280
新权重下"差5层等2小时"仍大于"同层刚入队"，楼层稳定主导排序；
极端 aging（>4h）仍能让同层任务被近楼层任务压制优先执行。
测试：QueueScoreCalculatorTest（3）、OrderQueueServiceEnhancedTest（1，
已按 selectBatchIds + selectActiveListByUserId 更新 mock）、QueueSyncServiceTest
全绿。
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
2026-04-20 13:32:24 +08:00 |
|
|
|
3e248fee8c
|
fix(ops): 补齐状态转换审计闭环，回滚场景也留痕到 bus_log
问题：ops_order_event 在主事务内写，事务 rollback 则整段记录消失；
若状态机转换抛异常或并发冲突被拒，线上只有控制台日志而无数据库审计，
运维难以追溯"是谁、在什么时候、尝试做了什么转换、为什么失败"。
设计：中央事件发布 + TransactionalEventListener 双阶段落盘
1. OrderTransitionAttemptedEvent（新）
覆盖 transition 成功、失败、FOR UPDATE 被拒三种情况，携带 orderId、
fromStatus、targetStatus、errorCode、errorMessage、causeSummary 等。
2. OrderLifecycleManagerImpl
- transition 成功分支：publishAttempt(success=true)
- transition 失败分支（context.hasError）：publishAttempt(success=false,
errorCode=INVALID_TRANSITION, cause=摘要)
- dispatch FOR UPDATE 命中分支：publishAttempt(success=false,
errorCode=ASSIGNEE_HAS_ACTIVE_ORDER)
publishAttempt 内部 try/catch，审计失败不影响主流程。
3. OrderTransitionAuditListener（新）
- @TransactionalEventListener(AFTER_COMMIT, fallbackExecution=true)
主事务已提交，按事件本身的 success 写 bus_log；INFO 级。
- @TransactionalEventListener(AFTER_ROLLBACK) + @Transactional(REQUIRES_NEW)
主事务已回滚，事件里声称的 success 强制视为失败；独立事务写 bus_log
避免因主事务回滚而日志同样丢失。
- errorCode、fromStatus、targetStatus、reason、cause 全部落 payload。
- 冲突（ASSIGNEE_HAS_ACTIVE_ORDER）→ WARN；其他失败 → ERROR。
4. LogType 新增 TRANSITION_FAILED、DISPATCH_REJECTED。
5. EventLogRecorder 接口补 recordSync（实现类已有同名方法）。
运维查询：按 eventDomain='dispatch' + eventLevel IN ('WARN','ERROR')
即可一眼看出所有"尝试但未成功"的状态转换。errorCode 留在 payload JSON 内，
未升级为一等字段（后续如需聚合统计再迁移）。
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
2026-04-20 13:11:28 +08:00 |
|
|
|
b534d79434
|
fix(ops): 派发入口加 FOR UPDATE 并发兜底，冲突时降级入队避免悬空
业务不变量：同一执行人在任一时刻最多只有 1 条活跃工单
（DISPATCHED/CONFIRMED/ARRIVED）。PAUSED 不纳入——P0 打断恢复
走 PAUSED→DISPATCHED，此处必须放行。
实现：
1. OpsOrderMapper.selectActiveByAssigneeForUpdate
查询 assignee 活跃工单并对命中行加 FOR UPDATE 排他锁。必须在
事务中调用。
2. OrderLifecycleManagerImpl.dispatch 入口校验
事务开启后立即执行 FOR UPDATE 查询，命中则返回带错误码
ASSIGNEE_HAS_ACTIVE_ORDER 的失败结果，不再执行责任链，
事务 commit 空操作、锁释放；并发竞争的第二个线程会阻塞到
第一个 commit 后看到活跃单，失败退出。
3. 新增 TransitionErrorCode 枚举 + OrderTransitionResult.errorCode
调用方可区分需降级的冲突与硬失败，避免把"可降级"的结果
直接抛给用户。
4. DispatchEngineImpl.executeDirectDispatch 降级逻辑
- 冲突 + 原状态 PENDING → 调 executeEnqueueOnly 降级到 QUEUED，
工单不悬空，等下一轮 autoDispatchNext 重挑。
- 冲突 + 原状态已是 QUEUED（并发另一路抢先派发时回滚保留）
→ 返回 fail 但不重复入队，天然等下一轮。
- 其他失败 → 照常 fail。
职责划分：
- 生命周期层负责"拒绝违反不变量的转换"
- 编排层负责"失败后给工单安置归宿"
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
2026-04-20 11:52:38 +08:00 |
|
|
|
c24b1eb641
|
fix(ops): 直接派发加空闲兜底 + 队列同步按活跃状态过滤
1. 直接派发空闲兜底（补 autoDispatchNext 之外的另一条派发入口）
DispatchEngineImpl.executeDispatch 在 DIRECT_DISPATCH/PUSH_AND_ENQUEUE
前增加 MySQL 兜底校验：若执行人仍挂活跃工单（Redis 判空闲但 MySQL
不一致的场景），强制降级为 ENQUEUE_ONLY 让任务进队列等待下一轮
autoDispatchNext 接力。避免同一设备再次出现并行多单。
2. 队列同步按活跃状态过滤
syncUserQueueToRedis / getTasksByUserId 的 MySQL 回填路径此前调用
selectListByUserId 不过滤状态，会把历史 REMOVED 记录一并同步到
Redis（线上观察到设备 31 的 Redis ZSet 塞了 206 条、其中 205 条是
REMOVED）。新增 OpsOrderQueueMapper.selectActiveListByUserId，只返
回 WAITING/PROCESSING/PAUSED，两条同步链路改走此方法。原 selectList
ByUserId 保留给审计/统计场景。
未清理历史 REMOVED 记录，保留审计追溯。
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
2026-04-20 11:22:18 +08:00 |
|
|
|
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 |
|
|
|
423bf3ec3f
|
feat(tenant): 实现 ProjectSecurityWebFilter 项目权限集合校验
新增 ProjectSecurityWebFilter:
- 集合校验: user.authorizedProjectIds.contains(header.projectId)
- 默认项目选择: DEFAULT编码 → 最小ID → 单项目自动选中 → 无授权403
- @ProjectIgnore URL 自动跳过
- 注册在 WebFilterOrderEnum.PROJECT_SECURITY_FILTER (-98)
框架层:
- ProjectCommonApi: 新增 getAuthorizedProjectIds, getDefaultProjectId
- ProjectFrameworkService: 新增授权查询 + Caffeine 缓存(60s/1000条)
- ViewshTenantAutoConfiguration: 注册 Filter + 扫描 @ProjectIgnore
业务层:
- ProjectService: 新增 getAuthorizedProjectIds, getDefaultProjectId
- ProjectServiceImpl: 默认项目3级回退逻辑
- ProjectApiImpl: 实现 Feign 端点
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-16 23:35:56 +08:00 |
|
|
|
c85f84ea46
|
test(tenant): Phase 4 — 项目隔离集成测试
新增测试 (33个全部通过):
- ProjectContextHolderTest (8 tests): set/get/clear/ignore/线程隔离
- ProjectUtilsTest (14 tests): execute/executeIgnore/嵌套调用/异常恢复
- DualInterceptorTest (11 tests): 双拦截器 SQL 注入验证 (已有)
DO 迁移验证:
- 15 个 DO 已迁移到 ProjectBaseDO (grep 确认)
- 3 个非迁移 DO 正确保持 TenantBaseDO
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-16 22:52:19 +08:00 |
|
|
|
a2f500fa20
|
feat(tenant): 租户-项目两级架构 Phase 2 — IoT + Ops 业务迁移
DO 迁移 (15个 TenantBaseDO → ProjectBaseDO):
- IoT: IotDeviceDO
- Ops 核心: OpsOrderDO, OpsOrderEventDO, OpsOrderDispatchDO, OpsOrderQueueDO,
OpsBusAreaDO, OpsAreaDeviceRelationDO, OpsDeviceTrajectoryDO
- Ops 保洁: OpsOrderCleanExtDO, OpsCleanerStatusDO, OpsCleanerPerformanceMonthlyDO,
OpsInspectionRecordDO, OpsInspectionRecordItemDO
- Ops 安保: OpsOrderSecurityExtDO, OpsAreaSecurityUserDO
IoT 适配:
- IotDeviceRespDTO 新增 projectId 字段
- IotDeviceMessage 新增 projectId 字段
- IotDeviceMessageServiceImpl.appendDeviceMessage() 设置 projectId
- IotCleanRuleMessageHandler 嵌套 ProjectUtils.execute() 设置项目上下文
缓存改造:
- ProjectRedisCacheManager extends TenantRedisCacheManager，追加 :projectId 后缀
- ViewshTenantAutoConfiguration 替换为 ProjectRedisCacheManager
SQL 迁移脚本 (sql/mysql/project/):
- 01-create-tables.sql: system_project + system_user_project 建表
- 02-default-data.sql: 默认项目 + 用户关联回填
- 03-alter-business-tables.sql: 15 张表添加 project_id (NULL → 回填 → NOT NULL → 索引)
- 04-index-audit.sql: 现有索引审计 + project_id 补充建议
- 99-rollback.sql: 完整回滚方案
附带修复:
- fix(ops): UserDispatchStatusServiceImpl 添加缺失的 KEY_PREFIX 常量
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-16 22:27:34 +08:00 |
|
|
|
87beb1228e
|
feat(tenant): 租户-项目两级架构 Phase 0+1 — 基础框架层
Phase 0 技术验证:
- ProjectBaseDO extends TenantBaseDO，新增 projectId 字段
- ProjectContextHolder (TransmittableThreadLocal) 项目上下文管理
- ProjectDatabaseInterceptor 实现 TenantLineHandler，返回 project_id 列
- 注册第二个 TenantLineInnerInterceptor，通过 @Qualifier 保证初始化顺序
- DualInterceptorTest 11 个用例验证双拦截器 SQL 注入（SELECT/INSERT/UPDATE/DELETE + JOIN + 子查询）
Phase 1 基础框架层:
- @ProjectIgnore 注解 + ProjectIgnoreAspect (SpEL 条件支持)
- ProjectUtils 工具类 (execute/executeIgnore)
- ProjectContextWebFilter 从请求 Header 解析 project-id
- WebFrameworkUtils 扩展 HEADER_PROJECT_ID + getProjectId()
- WebFilterOrderEnum 新增 PROJECT_CONTEXT_FILTER、PROJECT_SECURITY_FILTER
- RPC: TenantRequestInterceptor 自动透传 project-id
- MQ: Kafka/RocketMQ/RabbitMQ/Redis 全部支持 project-id 发送与消费
- @ProjectJob + ProjectJobAspect (@Order(2) 内层，配合 @TenantJob 使用)
- TenantJobAspect 补充 @Order(1) 外层标记
- ProjectDO + UserProjectDO + Mapper + ProjectService + ProjectController
- ProjectCommonApi (Feign) + ProjectApiImpl + ProjectFrameworkServiceImpl (Guava 缓存)
- TenantServiceImpl.createTenant() 联动创建默认项目
- ErrorCodeConstants 新增 1-002-030-xxx 项目错误码
Review 修复:
- Bean 初始化顺序: projectLineInnerInterceptor 依赖 @Qualifier 确保顺序
- computeIgnoreTable: @ProjectIgnore 检查优先于 isAssignableFrom
- ProjectFrameworkServiceImpl 注册为 Spring Bean
- RocketMQ SendHook: project-id 独立于 tenantId 传播
- createDefaultProject 移入 TenantUtils.execute 事务块内
- 全部 MQ/RPC 统一使用 HEADER_PROJECT_ID 常量
- ProjectJobAspect 增加租户上下文防御校验
- 移除 ProjectDO/UserProjectDO 无效的 @KeySequence
- ProjectServiceImpl/ProjectApiImpl 移除冗余 TenantUtils.execute 嵌套
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-16 19:22:57 +08:00 |
|
|
|
73e67dd3ec
|
Merge branch 'master' into feat/multi-tenant
Resolve conflicts by accepting master changes for:
- Jenkinsfile (CI/CD release/next branch support)
- OrderCodeGenerator (Redis seq sync fix)
- OrderCodeGeneratorTest (updated tests)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-16 18:08:14 +08:00 |
|
|
|
40a1593bb0
|
chore: init gsd
|
2026-04-16 15:28:49 +08:00 |
|
|
|
6bbd49355d
|
fix(ops): 修复工单编号生成器 Redis 序号与数据库不同步导致的重复编号问题
Java CI with Maven / build (11) (push) Has been cancelled
Java CI with Maven / build (17) (push) Has been cancelled
Java CI with Maven / build (8) (push) Has been cancelled
问题：Redis 重启或 key 过期后序号从 1 重新计数，与数据库已有编号冲突。
修复方案：
- 应用启动后首次生成时，从数据库查询当天最大序号校准 Redis
- 使用 Lua 脚本原子操作（校准 + 自增），避免并发竞态
- 后续调用走纯 Redis INCR，无额外数据库开销
- SQL 使用 deleted = b'0' 兼容 bit(1) 列类型
- LIKE 查询转义 % 和 _ 通配符
- 校准异常向上抛出，避免静默产生重复
- calibratedKeys 跨天自动清理旧条目
同步更新单元测试，覆盖校准、纯 Redis 自增、异常处理、SQL 转义等 13 个用例。
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-13 23:19:20 +08:00 |
|
|
|
7707455a24
|
feat(ops): 手动派单放宽校验，支持跨区域和向忙碌设备派单
移除 canAcceptNewOrder、区域绑定和区域匹配校验，仅保留在线检查。
手动派单由调度员人工判断合理性，自动派单的校验仍在 BadgeDeviceAreaAssignStrategy 中完成。
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-13 23:18:54 +08:00 |
|
|
|
ea374d131a
|
feat(ops): 工牌状态返回昵称字段，手动派单支持传入设备名称
- BadgeStatusRespDTO 新增 nickname 字段，透传设备昵称
- CleanManualDispatchReqDTO 新增 assigneeName，派单时携带设备显示名
- CleanWorkOrderServiceImpl 将 assigneeName 传递给派单引擎
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-13 23:18:30 +08:00 |
|
|
|
a32a4375bc
|
build(ci): CI/CD 支持 release/next 预发布分支
Java CI with Maven / build (11) (push) Has been cancelled
Java CI with Maven / build (17) (push) Has been cancelled
Java CI with Maven / build (8) (push) Has been cancelled
- Jenkinsfile: Deploy 和 Health Check 阶段支持 release/next 分支
- release/next 部署到 staging 服务器（172.17.16.7），master 部署到 prod
- 仅 master 分支推送 latest 镜像标签，避免预发布覆盖生产镜像
- GitHub Actions 添加 release/next 分支触发构建
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-13 14:44:20 +08:00 |
|
|
|
705717a5b1
|
Merge branch 'master' into feat/multi-tenant
# Conflicts:
# viewsh-module-ops/viewsh-module-environment-biz/src/main/java/com/viewsh/module/ops/environment/dal/redis/TrafficActiveOrderRedisDAO.java
# viewsh-module-ops/viewsh-module-environment-biz/src/main/java/com/viewsh/module/ops/environment/service/badge/BadgeDeviceStatusServiceImpl.java
# viewsh-module-ops/viewsh-module-ops-biz/src/main/java/com/viewsh/module/ops/service/dispatch/UserDispatchStatusServiceImpl.java
|
2026-04-13 14:35:27 +08:00 |
|
|
|
1ca472ea93
|
feat(iot): 客流计数器支持累计值上报模式（CUMULATIVE）
Java CI with Maven / build (11) (push) Has been cancelled
Java CI with Maven / build (17) (push) Has been cancelled
Java CI with Maven / build (8) (push) Has been cancelled
TrafficThresholdConfig 新增 reportMode 字段，支持 INCREMENTAL（默认）和 CUMULATIVE 两种模式。
累计值设备通过 Redis 存储上次值自动算差值，处理首次上报跳过和设备重启归零场景。
现有增量设备无需改配置，行为完全兼容。
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-09 13:59:20 +08:00 |
|
|
|
c8ba3e63cb
|
feat(iot): 新增恒华D5客流摄像机编解码器，对接拌线人数统计（type=1）
Java CI with Maven / build (11) (push) Has been cancelled
Java CI with Maven / build (17) (push) Has been cancelled
Java CI with Maven / build (8) (push) Has been cancelled
走通用路由，新增 IotHenghuaD5Codec 解析 form-urlencoded 格式数据，
映射 InNum/OutNum 到 people_in/people_out，业务层完全复用现有客流阈值逻辑。
IotHttpUpstreamHandler 增加恒华D5 专用简洁响应。
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-07 14:59:53 +08:00 |
|
|
|
04c61a41db
|
fix(ops): 修复 CleanBadgeServiceImpl 调用不存在的 queryAreaNameById 方法导致编译失败
Java CI with Maven / build (11) (push) Has been cancelled
Java CI with Maven / build (17) (push) Has been cancelled
Java CI with Maven / build (8) (push) Has been cancelled
改用 OpsBusAreaDO.getAreaName() 获取区域名称
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-07 10:45:10 +08:00 |
|
|
|
b379fc6741
|
feat(ops): timeline 接口 deviceId 改为可选，支持全设备查询
Java CI with Maven / build (11) (push) Has been cancelled
Java CI with Maven / build (17) (push) Has been cancelled
Java CI with Maven / build (8) (push) Has been cancelled
不传 deviceId 时查询该日期所有设备的轨迹记录，复用
selectByDateAndDevice 的 LIMIT 5000 安全上限。
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-05 15:27:05 +08:00 |
|
|
|
54f78f8066
|
feat(ops): 工牌实时状态增加物理位置、电量和工单信息
BadgeRealtimeStatusRespDTO 新增物理位置（IoT 轨迹检测 RPC）、
电量（IoT 设备属性 RPC）、当前工单信息三个维度。
RPC 调用改为串行执行避免占用 ForkJoinPool 公共线程。
设备状态写入 Redis 时同步写入区域名称。
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-05 15:26:43 +08:00 |
|
|
|
9ffaac5c91
|
feat(ops): 新增轨迹统计接口 summary/hourly-trend/area-stay-stats
- summary: KPI 卡片（作业时长、覆盖区域数、事件数、平均停留）
- hourly-trend: 按小时聚合出入趋势
- area-stay-stats: 区域停留分布（含 fullAreaName，按时长降序）
- deviceId 可选，不传则汇总全部设备
- selectByDateAndDevice 加 LIMIT 5000 安全上限
- 删除无调用方的 selectTimeline 方法
- enrichWithAreaInfo 改用 buildPaths 批量构建路径
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-05 15:26:14 +08:00 |
|
|
|
368fa90156
|
refactor(ops): 轨迹区域展示改用 fullAreaName 替代 buildingName/floorNo
TrajectoryRespDTO 移除 buildingName、floorNo 字段，新增 fullAreaName
（完整路径如"A园区/A栋/3层/男卫"）。AreaPathBuilder 新增 buildPaths
批量方法，一次查询所有父级区域避免 N+1；正则预编译为静态常量。
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-05 15:25:47 +08:00 |
|
|
|
9780d6c3f7
|
fix(ops): 区域设备 RPC 接口添加 @TenantIgnore 解决定时任务调用时租户上下文缺失
Java CI with Maven / build (11) (push) Has been cancelled
Java CI with Maven / build (17) (push) Has been cancelled
Java CI with Maven / build (8) (push) Has been cancelled
IoT 模块 BeaconRegistryServiceImpl 每30分钟通过 Feign 调用 /beacons/all 接口，
因定时任务无租户上下文导致 TenantContextHolder NPE。对跨租户查询的方法添加
@TenantIgnore 注解忽略多租户过滤。
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-04-01 09:23:27 +08:00 |
|
|
|
da00f08262
|
fix(environment): 对账修复后同步清理 TTS 循环播报
Java CI with Maven / build (11) (push) Has been cancelled
Java CI with Maven / build (17) (push) Has been cancelled
Java CI with Maven / build (8) (push) Has been cancelled
- BadgeDeviceStatusSyncJob 在修复设备工单一致性后额外停止 TTS 循环\n- 避免工单已清除但语音循环标记残留，导致设备继续播报\n- 对 TTS 清理失败增加 warn 日志，避免影响主对账流程
|
2026-03-31 22:58:40 +08:00 |
|
|
|
5d46502fb9
|
fix(ops): 启动时恢复工单队列缓存
- 新增 OrderQueueInitializer\n- 服务启动时调用 QueueSyncService.forceSyncAll()\n- 在 Redis 队列数据丢失或过期后，自动用 MySQL 数据回填 Sorted Set
|
2026-03-31 22:58:25 +08:00 |
|
|
|
306303ab16
|
fix(ops): 启动时校准人员调度状态
- 为 UserDispatchStatusService 增加基于 DB 的重建能力\n- 扫描 Redis 中的人员调度 key，按实际活跃工单数修正 status、activeOrderCount、waitingTaskCount\n- 新增启动初始化器，服务启动时自动执行一次校准，缓解事件丢失导致的 BUSY 残留
|
2026-03-31 22:58:09 +08:00 |
|
|
|
1696aeb287
|
fix(clean): 取消工单前先清理客流活跃标记
- 调整 CANCELLED 事件处理顺序\n- 先移除 area 级活跃工单 Redis 标记，再执行后续取消逻辑\n- 避免后续取消处理异常时遗留错误的活跃状态
|
2026-03-31 22:57:44 +08:00 |
|
|
|
f0fa5f1c46
|
fix(clean): 补齐客流活跃工单缓存自愈逻辑
- 为客流活跃工单 Redis 标记补充 TTL，避免长期残留\n- 创建工单前命中 Redis 时回查 DB，自动清理终态脏数据并刷新过期状态\n- 新增启动校准器，服务启动时批量清理或刷新 area 级活跃工单缓存
|
2026-03-31 22:57:28 +08:00 |
|
|
|
d3eecc63ef
|
feat(trajectory): 新增轨迹后台查询与实时位置接口
- 新增轨迹分页、时间线、统计摘要等查询 DTO\n- 提供轨迹后台控制器，支持工牌下拉、轨迹查询、实时位置查询\n- 接入 TrajectoryStateApi 的 Feign 配置，打通 Ops 对 IoT 实时位置状态的读取
|
2026-03-31 22:56:49 +08:00 |
|
|
|
bf5aa21648
|
feat(trajectory): 新增轨迹事件消费与落库模型
- 新增 ops_device_trajectory 表及轨迹数据对象、Mapper\n- 消费 trajectory-enter / trajectory-leave 事件并做幂等处理\n- 落地设备进入/离开区域记录，补充停留时长与离开原因字段\n- 在服务层封装轨迹写入、关闭未离场记录等核心逻辑
|
2026-03-31 22:56:18 +08:00 |
|
|
|
11dcb57ff3
|
feat(trajectory): 新增轨迹检测与 Beacon 注册表
|
2026-03-31 22:53:06 +08:00 |
|
|
|
4c3350377e
|
build(ci): hardcode stage deploy target
|
2026-03-30 23:37:02 +08:00 |
|
|
|
9e2b510cb8
|
build(ci): limit latest image pushes to master
|
2026-03-30 23:23:44 +08:00 |
|
|
|
90fa54dc11
|
build(ci): add stage deployment pipeline and configs
|
2026-03-30 22:53:46 +08:00 |
|
|
|
19cb25b0ea
|
refactor(ops): 15 个 DO 基类从 BaseDO 规范化为 TenantBaseDO
Java CI with Maven / build (11) (push) Has been cancelled
Java CI with Maven / build (17) (push) Has been cancelled
Java CI with Maven / build (8) (push) Has been cancelled
数据库表已有 tenant_id 列，拦截器实际可正常工作，但 DO 继承
BaseDO 语义不明确。统一改为 TenantBaseDO 以明确租户隔离语义。
ops-biz: OpsOrderDO, OpsOrderDispatchDO, OpsOrderEventDO,
OpsOrderQueueDO, OpsBusAreaDO, OpsAreaDeviceRelationDO,
OpsBusinessEventLogDO
environment-biz: OpsOrderCleanExtDO, OpsInspectionRecordDO,
OpsInspectionTemplateDO, OpsInspectionRecordItemDO,
OpsCleanerStatusDO, OpsCleanerPerformanceMonthlyDO
security-biz: OpsOrderSecurityExtDO, OpsAreaSecurityUserDO
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-03-30 11:42:09 +08:00 |
|
|
|
fef3e13ff4
|
fix(iot): IoT 事件发布补充 tenantId 并修复租户上下文缺陷
7 个事件构建点补充 .tenantId(TenantContextHolder.getTenantId())：
- TrafficThresholdRuleProcessor: CleanOrderCreateEvent
- BeaconDetectionRuleProcessor: CleanOrderArriveEvent, CleanOrderAuditEvent
- SignalLossRuleProcessor: CleanOrderCompleteEvent, CleanOrderAuditEvent
- ButtonEventRuleProcessor: confirm/query 事件 Map
其他修复：
- IotSceneRuleMessageHandler: 添加 TenantUtils.execute() 包裹
- SignalLossRuleProcessor: 硬编码 execute(1L) 改为从设备动态获取
- 更新 SignalLossRuleProcessorTest 和 RssiSlidingWindowDetectorTest
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-03-30 11:41:41 +08:00 |
|
|
|
7d19e7bafa
|
fix(ops): RocketMQ 消费者添加租户上下文防御性兜底
6 个消费者添加 executeInTenantContext() 统一模式：当框架 Hook
未设置租户上下文时，从事件体 tenantId 字段兜底切换。
同步为 4 个事件 DTO 添加 tenantId 字段，去重 Key 迁移至
OpsRedisKeyBuilder.eventDedup() 实现租户隔离。
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-03-30 11:41:14 +08:00 |
|
|
|
74f6207843
|
fix(ops): XML 手写 SQL 添加 tenant_id 预编译参数过滤
yudao 官方明确 MyBatis Plus 拦截器不处理 XML 手写 SQL，需手动过滤。
将 ${} OGNL 表达式改为 #{tenantId} 预编译参数，避免 NPE 和
@TenantIgnore 不兼容问题。
- OpsOrderMapper: 8 条统计 SQL 添加 AND tenant_id = #{tenantId}
- OpsTrafficStatisticsMapper: deleteByStatHourBefore 补上 tenant_id
- OpsStatisticsServiceImpl: 10 处调用传入 tenantId 参数
- TrafficStatisticsCleanupJob: executeIgnore → @TenantJob + 显式传参
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-03-30 11:40:39 +08:00 |
|
|
|
df2d14ce26
|
feat(ops): 新增 OpsRedisKeyBuilder 统一管理 Redis Key 租户隔离
新建 OpsRedisKeyBuilder 集中式工具类，所有 Ops 模块 Redis Key 统一使用
:t{tenantId} 格式实现多租户隔离。迁移以下服务的 Key 构建：
- RedisOrderQueueServiceImpl（派单队列/信息/锁）
- UserDispatchStatusServiceImpl（调度状态）
- BadgeDeviceStatusServiceImpl（工牌状态）
- TrafficActiveOrderRedisDAO（客流活跃工单）
- TtsQueueConsumer（TTS 队列/锁/循环）
- OrderCodeGenerator（工单编码序号）
- AreaDeviceServiceImpl（区域设备配置缓存）
- TrafficStatisticsPersistJob（持久化锁）
- BadgeDeviceStatusRedisDAO（IoT 侧工牌状态）
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-03-30 11:36:18 +08:00 |
|
|
|
a9941a29a9
|
fix(ops): 状态机允许 CONFIRMED → COMPLETED，支持安保确认后直接完单
Java CI with Maven / build (11) (push) Has been cancelled
Java CI with Maven / build (17) (push) Has been cancelled
Java CI with Maven / build (8) (push) Has been cancelled
安保工单不需要信标到岗检测（ARRIVED），确认接单后可直接提交处理结果完成。
原规则 CONFIRMED → {ARRIVED, CANCELLED} 缺少 COMPLETED，导致安保人员完单报错：
"非法状态转换: CONFIRMED -> COMPLETED"
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-03-27 17:11:49 +08:00 |
|
|
|
edf0a3e645
|
fix(clean): 修复 CleanOrderEndToEndTest 编译错误
Java CI with Maven / build (11) (push) Has been cancelled
Java CI with Maven / build (17) (push) Has been cancelled
Java CI with Maven / build (8) (push) Has been cancelled
sendPriorityUpgradeNotification 已从 CleanOrderEventListener 移至
CleanOrderNotificationService，测试中 verify 目标未同步更新。
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-03-27 16:38:56 +08:00 |
|
|
|
55ef659364
|
feat(ops): 手动派单遵循执行人忙碌状态，忙碌时入队等待
ManualOrderActionFacade.dispatch：
- 新增 strategy.isAssigneeIdle() 判断，空闲→DISPATCHED，忙碌→QUEUED
- 不再无条件直接派发
OrderBusinessStrategy：
- 新增 isAssigneeIdle() 默认方法，默认返回 true
CleanOrderBusinessStrategy：
- isAssigneeIdle 通过 BadgeDeviceStatusService.isBusy() 判断设备忙碌
SecurityOrderBusinessStrategy：
- isAssigneeIdle 通过 UserDispatchStatusService.isIdle() 判断人员忙碌
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-03-27 16:37:30 +08:00 |
|
