2026年08月03日
内容截止日: 2026年08月09日
本周工作计划与执行完成进度
中心服务平台 - 功能完善
- 进度: 🔘 未开始 -> 🟡 进行中 -> ⚠️ 部分完成 -> ✅ 已完成 -> 📌 已自测
以往已完成的工作不再重复,详情请查看上周及上月报告- 〔工作量〕es-center-server-services 51 次(设计 28 · 代码 23)· 代码 +7.1k/-1.0k | es-center-server-web-app 45 次(设计 15 · 代码 30)· 代码 +11.9k/-3.2k | es-center-server-install-app 2 次 · 代码 +0.1k/-0.1k | es-center-server-build 1 次
- 〔方法论〕流程逐项评审与审查纠偏 | 按当前关系派生配置、提交后刷新 | 状态所有权拆分与有界恢复 | 队列限流与窄范围磁盘补偿
- 8-03 ~ 8-04: 对讲配置刷新
- ✅ 群组与设备关系变更后,统一刷新 PTT 配置 〔es-center-server-services〕
设计PTT(按键对讲)配置按当前关系临时计算、不另存快照。ADR-0015(架构决策记录)明确推送与 retrieve(拉取配置)共用一个下发入口,并补齐对讲群组术语。设计建立「一流程一会话」的工作台,前端 API 清单单列;补上手动 pushPttConfig(向设备推送对讲配置)流程,并先按设备绑定全量替换记录。评审grilling(逐条追问的设计评审)分别核对新增、更新、删除、设备绑定和定时建房流程。审查核对 plan-01 更新流程后纠偏 ADR-0015:群组组合更新实际是设备绑定增量同步。发现消息、操作日志在 commit(事务提交)前发送,以及 REMOVE 设备漏推配置两处问题,建立修复批次。设计关系刷新规格拆成共享群组刷新、设备侧组合更新、关系单删/批删三步。消息只携带影响范围,提交后 best-effort(尽力执行、不保证送达),不把数据库事务成功扩大为设备全部收到配置。实施群组保存、更新、单删和批删复用同一刷新组件,清理关系后再投递;设备侧变更与关系单删/批删增加独立 JMS(服务间异步消息)入口,校验消息租户、去重群组并复用共享刷新。实施消息与操作日志改到事务提交成功后发送;无事务时仍立即执行,回滚或提交失败不发送,日志失败与已提交业务隔离。
- ✅ 本地开发存储迁到持久挂载目录 〔es-center-server-services〕
实施device/main-service 的日志、TUS 上传、files、firmware-package 与 data-sync 路径由 /tmp 迁到 WSL 持久挂载,避免随重启清空开发数据。
- ✅ 群组与设备关系变更后,统一刷新 PTT 配置 〔es-center-server-services〕
- 8-03 ~ 8-04: 房间恢复方案
- ✅ 掉房诊断与恢复规格定稿,公开类型按拆分基线固定 〔es-center-server-web-app〕
设计记录掉房(对讲房间意外断开)的诊断与执行方案。AudioBridge(Janus 音频会议插件)的 hook(可复用的前端逻辑函数)按成员出席、信令和浏览器音频会话拆成三个所有者,形成渐进计划。设计发话方式验收约束、麦克风拒绝后降为只听的决策补进 ADR;恢复与本地发话规格定稿,拆出 12 张实施票,包含恢复裁决、重试上限、音量、成员生命周期和集成验证。审查完成 hook 拆分的 G0 阶段验证,保留验证记录。重构AudiobridgeRoomViewState/AudiobridgeRoom 的只读公开类型作为本次拆分合同固定,这是调用方与实现方本阶段共用的约定。测试门禁测试按公开类型合同同步对齐。设计更新 AI 工作流模板与 Talkgroup 渐进计划,模板改为生成编排文档,不绑定 CLI 语法。实施清理 .tmp 历史截图与快照。
- ✅ 掉房诊断与恢复规格定稿,公开类型按拆分基线固定 〔es-center-server-web-app〕
- 8-04: 启动配置与发布物
- ✅ 分块传输配置停用覆盖项,启动等待与安装版本同步调整 〔es-center-server-install-app〕
实施模板、升级包和现行 nginx/Web App 配置注释停用 chunked_transfer_encoding(HTTP 分块传输)覆盖项。PostgreSQL、ActiveMQ、EMQX、设备服务、Janus 和 Meilisearch 的逐项启动等待由 8 秒延长到 16 秒,启动前增加 180 秒等待;测试辅助补设备服务与 launcher 停止命令。实施构建版本号更新到 20260804,主服务、设备服务、Web App 镜像及各目标构建、安装、升级、上传入口由 06-24 批次统一推进到 08-04 发布物。
- ✅ 构建仓同步 Web 与双服务的 08-04 发布物 〔es-center-server-build〕
实施活动 Web 构建切回另一协作分支,后端源基线推进到 07-30;四个目标的 SCP/SFTP(文件上传协议)与远端加载引用同步,辅助脚本补既有 Web 镜像上传至测试目标及正式目标备份目录的入口。
- ✅ 分块传输配置停用覆盖项,启动等待与安装版本同步调整 〔es-center-server-install-app〕
- 8-05: 前端房间恢复
- ✅ 三类房间状态各自管理,恢复按健康状态与重试边界执行 〔es-center-server-web-app〕
重构分别抽出成员出席、AudioBridge 信令、浏览器音频会话所有者,把每类状态的唯一管理权交给对应模块。实施receiver-first(先收后发)本地发话链路交付;建立确定性恢复主干,按会话健康与房间可用性决定是否恢复。错误分类、失败阶段与重试上限组成有界恢复,避免无限重试。实施播放音量与 autoplay(自动播放)解锁统一处理;补齐成员状态生命周期、小屏响应式房间主控与减少动画设置,状态栏增加分隔线。设计AudioBridge issue 08 的目标及后续实施日志持续记录,区分有界重试、音量、响应式主控和集成验证阶段。
- ✅ 三类房间状态各自管理,恢复按健康状态与重试边界执行 〔es-center-server-web-app〕
- 8-05 ~ 8-06: 群组删除与定向刷新
- ✅ 群组与绑定在同一事务删除,设备侧改为只刷新目标设备 〔es-center-server-services〕
审查完成对讲群组流程现状复核,按当前前端入口与后端实现补五步流程、自动化回归及已接受边界;群组更新复核保留部分成功、默认群组并发、前端忽略 data=false 和房间名称未进入 UI 的事实。设计群组原子删除与提交后实时处理分成两步。数据库删除要么成功、要么回滚;提交后的销房、PTT 刷新仍各有失败边界。实施10 个 plan 流程统一命名为 workflow,引用一并更新。实施群组单删/批删先逻辑删除群组,再清理有效绑定,持久化异常整体回滚。提交后按输入顺序销毁全部房间,全部成功后才整批刷新一次 PTT;销房失败向上传播并停止后续动作。实施新增群组优先投递建房任务;投递失败记录后交周期补偿,仍继续尝试 PTT 刷新。重构TalkGroup(对讲群组)监听器改为完整显式构造注入,避免半初始化;保持消息顺序和失败行为。设计设备侧 PTT 刷新规格修正,明确组合更新只刷新目标设备。独立关系新增没有前端入口,关系单删/批删专用消息也不再保留,定向刷新实施票据此发布。重构设备侧在消息租户内查询目标设备,只投递一次 D2(配置刷新消息);删除无前端入口的关系消息、监听器和专用逻辑删除查询。测试workflow-02 审查遗留项关闭,单删/批删失败合同改为参数化测试并保留全部 6 次执行。审查workflow-03 复核对齐最终定向刷新实现及 best-effort 边界。
- ✅ 群组与绑定在同一事务删除,设备侧改为只刷新目标设备 〔es-center-server-services〕
- 8-06: 入房权限与成员列表
- ✅ 入房动作权限统一,周期补偿与删除参数约束补齐 〔es-center-server-services〕
审查设备侧群组绑定流程复核完成,后端工作台记录需求、检查点、待维护者决策与最终规格取舍。设计ensureRoom(确保房间存在)与 pushPttConfig 统一采用关系 read 权限;TalkGroup 删除 ID 类型合同、Meilisearch(平台搜索引擎)队列与历史保留形成实施规格。实施两个入房入口统一为 administrator 或关系 read 权限,撤销 ensureRoom 只需登录的例外。personnel、department-management、team-management 三个默认角色补群组页面与业务权限,保持各自数据范围;Janus 权限前缀统一为 device-janus-server:*。实施周期补偿每 288 轮全量扫描建房/销房,1440 轮重合时全量优先;保留启动、三个月与一个月候选扫描。单删拒绝非字符串 ID,批删只传有效字符串原值,无有效项即停止,警告不记录原始 ID。实施运行配置统一 Druid 等待/统计和 JetCache 本地容量;清退未生效 Lettuce pool、Actuator management、Disruptor alias 及相关构建引用。
- ✅ 房间显示成员花名册,进房前校验并刷新配置 〔es-center-server-web-app〕
设计成员体验与进房 PTT 刷新规格、实施票先后完成。成员体验拆出 10 张实施票,规划覆盖契约冻结、参与者编码、事件优先校准、在线查询合并、花名册、搜索/过滤/排序/无障碍、绑定设备入群通知、临时设备批量入群通知、集成验证和 live PCMA(真实设备上核验 PCMA 音频编码)验收;该真实设备验收保留为规划范围。设计设备入房请求合同作为本次实现基线固定;成员面板以绑定设备为底,区分 PTT 在线与房间出席状态,未知 codec(音频编码)回退 PCMA。实施Web 参与者按群组 codec 配置设置;同步改为事件优先,导航权限校准,绑定设备在线查询合成一次请求并校准成员状态。实施从群组信息派生成员花名册,补搜索、过滤、排序与无障碍体验;新增绑定设备入房通知和临时设备批量入房通知。实施入房请求阻止重复与未就绪操作,入房时刷新 PTT 配置。测试补齐成员体验集成验证。
- ✅ 入房动作权限统一,周期补偿与删除参数约束补齐 〔es-center-server-services〕
- 8-07 ~ 8-09: 索引限流与历史保留
- ✅ 五类历史索引队列有处理上限,磁盘补偿与六个月保留按窄边界执行 〔es-center-server-services〕
设计队列、spool(磁盘暂存区)与 retention(历史索引定期清理)拆出实施入口;ADR 限定磁盘补偿只处理「历史 JSON 已序列化、提交索引抛异常」,队列满、解析/序列化失败及 snapshot(快照索引)不扩大为可靠消息保证。实施磁盘 pending 文件按来源隔离、原子写入并检查剩余空间,支持单文件恢复,非法文件隔离,提交或删除失败保留证据。实施GPS、MyLog、Battery、MQTT Connection、ZFYGB 五队列各限制 10,000 项,每轮最多 10 批、每批 1,000 项;满队列拒绝最新项,只有上述窄失败写入 spool,后续空闲轮次尝试恢复,保留 at-most-once(最多处理一次)的主语义。实施五类调度各累计 144,000 轮才触发历史保留检查,只删除严格早于 UTC 六个月、名称可解析的日/月索引;snapshot 和未知名称保留,枚举或删除失败即停止清理。
- ✅ 历史设计状态与测试手册按当前实现更新 〔es-center-server-services〕
设计虚拟线程历史 tracker 关闭,9 篇对讲历史流程标明已实施或被取代边界。O3/L2 历史 request 与 owner(维护者)决策对齐:客户端只产生一个可用 transaction(请求关联标识),未执行的 L2 日志优化保留为 OPTIONAL/WONTFIX。设计新增版本分层测试手册与复用模板,分非专业变化、专业测试、开发审查三层,突出 Janus 权限码的破坏性变更风险。测试手册登记 634 项自测全绿。实施删除零业务价值的空 prompt(提示词)和通用元指令文件。
- ✅ 五类历史索引队列有处理上限,磁盘补偿与六个月保留按窄边界执行 〔es-center-server-services〕
- 8-07 ~ 8-09: 对讲视觉对齐
- ✅ 对讲界面的页头、状态、工作台和保存流程按设计稿调整 〔es-center-server-web-app〕
实施引入 Agent skills。设计记录对讲功能测试清单与设计审查材料,拆出设计再对齐实施票。实施页头与状态呈现统一;工作台搜索、卡片与选择、设备工作区信息层级、新增与管理保存及绑定区段按设计稿再对齐。
- ✅ 对讲界面的页头、状态、工作台和保存流程按设计稿调整 〔es-center-server-web-app〕
其它工作
- 目标: 记录日常杂项工作、协作沟通等事务
- 进度: 🔘 未开始 -> 🟡 进行中 -> ⚠️ 部分完成 -> ✅ 已完成 -> 📌 已自测
- 📌 以往已自测工作不再重复,详情请查看上周及上月报告
- 03 日
- ✅
协作git → svn 源代码同步 - ✅
实施zxs-cs及zxs服务器上 nginx 配置改进: 处理孙工反馈的设备端获取云服务器节点分配信息失败率较高的问题
- ✅
- 04 日
- ✅
实施最新程序编译 → 制作 docker 映像 → 制作升级程序 → 上传zxs服务器 → 升级部署 - ✅
文档编写并提供给测试人员测试手册与版本更新日志(告知本次测什么) - ✅
排障郭工反馈 app 上部分设备在线状态与真实不符- 现象: app 显示在线状态不准;web 端无此问题
- 排查: 用 AI 辅以 Linux MQTT 客户端订阅消息分析,核对前后端源代码,并用 MCP 控制浏览器对比 web 与 app 产生的 MQTT 消息
- 根因一(采样机制): web 利用 MQTT 主题双向通信特性——调用接口时传参设置「连续 3 次、每间隔 3 秒回复一次最新在线状态」,一次请求即得多次采样,设备 WebRTC client 频繁断连时也容易捕到 true;app 未用此机制、仅单次采样(且 15 秒才轮询一次),断连瞬间易命中 false
- 改进: app 改用与 web 相同的多次采样机制
- 根因二(批量 vs 单个): app 一次调用只获取一个设备的在线状态,而 web 一次可获取上千个;如同买 100 个鸡蛋,跑 1 趟买 100 个比跑 100 趟每次买 1 个高效
- 改进: app 改为一次性批量获取所有设备的在线状态
- ✅
Last updated on