Seetong · Report

🎯 Seetong 问题雷达 17:00 第248期

时间窗口：2026-10-22 09:00:32～2026-10-22 17:00:00（Asia/Shanghai）

📌TL;DR 核心要点

  • 🟠 iOS 8.4.106 一键重置密码在授权 token 过期后只显示失败，不自动重新校验，也没有可恢复入口：同一用户连续提交两次，Sensors 与 Logan 均直接记录 30000126，其中 61 秒内连续失败 3 次。严重度 65 / 100，现象与错误链置信度强，沿用任务 T-20261015-090316-0dda。
  • 🟠 iOS 8.4.1.6 扫码添加设备时，旧随机码轮询未停止，页面持续收到 30200111 绑定随机码不存在，同时其他随机码已返回成功：同一用户 4 分钟内提交两次，Logan 暴露旧 timer 与新一轮绑定并发。严重度 65 / 100，现象置信度强，根因置信度中，新建任务 T-20261022-170642-c470。
  • 258852、258853：iOS 8.4.1.6、iPhone 26.6.1、山东泰安，同一 clientId 033E1054-ABCB-44D3-8634-08B0D232B5B9、同一 IP，在 12:07:01 与 12:08:19 连续提交“重置密码失败(30000126)”。

🔥最近一个月 Top 问题

按严重度与复发期数排序，已把跨期同类反馈归集；负责人由问题代码锚点对应的 Git 提交历史（blame / 近期主要提交者）反查；数据窗口：最近 30 天（截至 2026-10-22）。

#问题（严重度降序）严重度平台版本负责人问题原因
1Android 8.4.1.6 及 HarmonyOS 1.1.1.11 单设备随机离线、P2P 恢复失败
20 期 · 164 条反馈
100Android · HarmonyOS1.1.1.11 / 8.4.1.6 / 1.1.2.3陈宝旺、唐胜、冉博麟、谭伟257582、257639 已确认是服务端心跳长期停更并伴随 P2P 离线，App 只是按离线状态展示；问题更可能在设备端、设备网关／P2P 服务或固件恢复机制，而不是 Android 播放器单点故障。
2Android 与 iOS 8.4.1.6 报警功能突然失效与通知不达
1 期 · 3 条反馈
90Android · iOS8.4.1.6唐胜、许源现有客户端样本表明 Android 通知权限与 token 注册均成功，故障更接近“服务端未生成报警或推送任务未送达”，但神策缺少报警生成与推送到达事件，iOS 样本又混合了通知权限关闭，当前不能完成单点定因。
3HarmonyOS 画中画状态导致切换设备后仍显示前一路画面
1 期 · 3 条反馈
90HarmonyOS1.1.1.11 / 1.1.2.3张跃译多个 HarmonyOS 画面共享一个无代次、无串行化、无旧控制器清理的 PipManager，切换设备时旧创建任务和新选择竞争，最终把第一路 XComponent、savId 或恢复状态保留下来。
4升级后回放体验整体退化
4 期 · 18 条反馈
85Android · iOS8.4.1.6 / 8.3.14.2唐胜、许源、欧阳荣、谭伟8.4.1.6 对回放链路做了多处改动（时间条 UI、通道切换进度对齐、报警-录像联动），导致回放体验多点退化；Logan 显示取流层无崩溃，问题在"UI/状态对齐 + 报警录像关联"而非连接失败。
5KMP 回放页未申请屏幕常亮，回放中手机自动息屏
11 期 · 29 条反馈
84Android · HarmonyOS8.4.1.6 / 8.4.1 / 8.4.2唐胜、陈宝旺、许源、谭伟KMP 回放页的屏幕常亮能力已在代码中完整实现（KMP 公共层 → 桥接层 → Android 宿主层齐备），但承载该实现的提交只落在 feature_v8.4.2 一条分支上，feature_v8.4.4、master、hotfix_v1.1.1 全部不含，因此所有已发布版本（Android 8.4.1.6 / HarmonyOS 1.1.1.11）在运行时都走不到 FLAG_KEEP_SCREEN_ON，回放过程中发生系统级息屏。
6Android 实时预览无首帧却被标记为“视频播放中”，并无限重试
5 期 · 12 条反馈
80Android · iOS8.4.1.6 / 8.4.1.4唐胜、张威、谭伟、欧阳荣预览页把“取流请求已提交”或“设备在线状态消息”误当成播放成功，而没有把首帧到达作为唯一成功门禁；add_watch_result=-1 后仍持续 10 秒重试并显示“视频播放中”，导致用户长时间等待且无法获得明确失败反馈。
7SD 卡跌至不可读写或反复未初始化，录像回放被直接阻断
3 期 · 9 条反馈
80Android · HarmonyOS · iOS8.4.1.6 / 1.1.1.11唐胜、张威、陈宝旺设备上报的 SD 卡状态在 258245 中持续处于未初始化／格式化中，在 258173 中由正常可读写跌至不可读写；App 按协议正确展示异常，根因更可能在 SD 卡、卡槽／供电、设备存储控制器或固件挂载逻辑，而不是 KMP 页面误报。
8iOS `8.4.1.6` 云回放卡顿，首帧与失败状态可能被提前结算
2 期 · 8 条反馈
80Android · iOS8.4.1.6 / 8.3.11.3 / 8.4.106陈宝旺、欧阳荣、谭伟iOS 云回放容器允许解析完成后在 1.2 秒无首帧时提前向 KMP 返回成功，同时把 IJK 播放错误与正常结束合并处理，导致页面对真实卡顿、缓冲超时或解码失败缺少准确状态和可回溯证据；这是高度可疑的共同客户端缺陷，但仍需复现确认其是否为 3 名用户的直接主因。
9iOS 8.1.2.4 微信登录授权码重复提交触发 30100225
1 期 · 3 条反馈
80iOS8.1.2.4 / 8.1.204 / 8.4.106待定微信回调与恢复登录没有一次性 state、幂等锁和授权码消费机制，重复回跳或重试会把同一个单次授权码再次发给服务端，服务端以 30100225 拒绝后客户端仍保留旧状态。
10iOS 老版本微信登录空授权码触发 30100222
1 期 · 1 条反馈
80iOS8.1.3.5 / 8.1.305 / 8.1.503位冬微信授权回跳在当前旧版 iOS 上返回了空 code，客户端没有把它视为失败边界，仍向服务端提交空授权码，最终稳定触发 30100222。

🟠 问题 1：iOS 一键重置密码在授权 token 过期后无法恢复 ｜ 负责人：谭伟、位冬

1. 现象与覆盖范围

  • 258852、258853：iOS 8.4.1.6、iPhone 26.6.1、山东泰安，同一 clientId 033E1054-ABCB-44D3-8634-08B0D232B5B9、同一 IP，在 12:07:01 与 12:08:19 连续提交“重置密码失败(30000126)”。
  • 用户走的是“一键重置”路径。这个错误并非网络中断，而是提交新密码时 checkCode 对应的授权 token 已过期。
  • 涉及反馈：2 条，但属于同一用户短时间重复提交，独立用户数按 1 计。
  • 严重度评分：65 / 100。反馈量 10（1 名独立用户）、共性广度 30（iOS、8.4.106、iPhone 机型、山东地区）、业务关键度 25（账号找回被阻断）。
  • 去重判定：任务账本已有 T-20261015-090316-0dda，本期是该问题的再次发生和直接证据补充，不重复创单。

2. Sensors 证据

  • 2026-10-22 09:00 至 17:00，iOS 8.4.106 的 ForgetPassword 共 1,003 次，其中 error_code=30000126 为 5 次 / 2 UV，占当日密码重置事件的 0.499%。
  • 精确映射到 Logan 用户 59061624，该用户在 12:06:39、12:07:06、12:08:02 连续上报 3 次“一键重置 + 30000126”，与两条反馈的时间及路径一致。
  • 近 7 天 iOS 8.4.106 的 30000126 次数依次为 2、5、3、4、1、11、5，发生率依次为 0.106%、0.257%、0.146%、0.210%、0.056%、0.610%、0.499%。10 月 21 日和 22 日处于近 7 天高位，虽样本不大，但与本窗口连续复现一致。
  • ForgetPassword 事件中的 reset_way 能直接区分一键重置、手机号重置和邮箱重置，因此本次错误口径不是从其他登录失败事件推断出来的。

3. Logan 关键日志

  • 反馈 ID：258852，Logan 文件 3d1b83a3-bb87-4e24-9925-3ce0b8dd135a.log.gz，共 1,383 行。
  • 12:00:08.272：POST /seetong-client/password-reset/local-number/check，首次本机号码校验返回 200。
  • 12:06:39.119：再次请求 POST /seetong-client/password-reset/local-number，请求已携带新密码和先前取得的 checkCode。
  • 12:06:39.448：服务端返回：
{"code":30000126,"success":false,"msg":"授权token已过期","rid":"7388392499334dcfb8bcc16b37f96d60"}
  • 12:06:39.448：同一条客户端请求日志确认 path=/seetong-client/password-reset/local-number,ret=30000126。
  • Sensors 中同一用户随后在 12:07:06、12:08:02 仍重复“一键重置 + 30000126”，说明用户没有得到“重新校验”或“重新发起一键验证”的恢复路径，只能反复点提交。

4. 代码定位

  • 涉及模块：Seetong-App-iOS/Seetong5.0_ios/Seetong_tps/Classes/Login/Controller。
  • STForgetPwdViewController.mm:702-742：checkLocalNumberRequestWithToken 调用 kAPIResetPwdNumberCheck，成功后把服务端返回的 checkCode 写入 STOneKeyResetPwdViewController.token。
  • STOneKeyResetPwdViewController.m:129-164：shanYanOneResetPasswordWithToken 把该 token 原样当作 checkCode 提交到 kAPIResetPwdLocalNumber。失败分支上报 responseModel.code 后只显示通用失败，没有针对 30000126 重新校验或重新打开闪验授权。
  • STResponseModel.h:88：STRequestRegisterErrorCodeTokenExpire = 30000126，客户端已经明确知道该错误语义。
  • 调用链为：一键重置入口 → shanYanOneResetPasswordWithToken → checkLocalNumberRequestWithToken → 获得 checkCode → 用户输入新密码 → STOneKeyResetPwdViewController.shanYanOneResetPasswordWithToken → kAPIResetPwdLocalNumber → 30000126 → 通用失败提示。
  • 关键分支缺陷：30000126 与账号不存在、手机号不匹配、普通网络错误共用失败处理，客户端没有识别“授权凭证失效”，导致 token 一旦过期，整个页面只能失败。

5. 根因结论

  • 置信度：现象 🟢 强；客户端缺少过期恢复链路 🟢 强；服务端 token 的具体 TTL 触发条件 🟡 中。
  • 一句话根因：一键校验产生的 checkCode 在提交新密码时已经过期，但 iOS 客户端没有在 30000126 后重新发起一键校验，用户只能在失效 token 上反复重试。
  • 关键证据链：输入密码后的 local-number 请求直接返回 30000126 → Sensors 同一用户连续 3 次上报相同错误 → 客户端代码只做通用错误提示，没有过期恢复分支。

6. 建议下一步

  • 分配给：iOS 登录模块负责人；代码历史锚点为谭伟，近期重置密码埋点改动涉及位冬。状态保持 P1 / captured。
  • 在 STOneKeyResetPwdViewController 的失败分支单独识别 STRequestRegisterErrorCodeTokenExpire，立即重新调用一键本机号码校验并换取新 checkCode，不得继续使用旧 token。
  • 若闪验 token 同步失效，应返回“重新验证本机号码”的明确按钮并保留已输入的账号信息，避免用户重新走完整流程。
  • 增加 checkCode 获取时间、提交时间、等待时长、请求序号和错误码埋点，用于量化自然过期与页面停留过久。
  • 回归覆盖取得 checkCode 后等待 1 分钟、5 分钟、10 分钟再提交，以及连续点击提交 3 次、切后台再返回、闪验授权失败后重试各 20 次。

🟠 问题 2：iOS 扫码添加设备复用过期随机码并持续轮询

1. 现象与覆盖范围

  • 258876：14:37:47，iOS 8.4.1.6、iPhone 26.6.2、青海西宁，反馈“一直断网，填加不了设备”。
  • 258878：14:41:00，同一用户、同一设备、同一 clientId 6F477DA6-EB64-4CB2-B165-DF6EAE922B01，反馈“联网后一直添加不了设备”。
  • 现象不是单纯网络提示：Logan 明确记录旧 randCode=82785985 在约 3 分钟内持续返回“绑定随机码不存在”，而新生成的 randCode=36930677 已返回 200，页面仍保留旧轮询。
  • 涉及反馈：2 条，属于同一用户重复提交，独立用户数按 1 计。
  • 严重度评分：65 / 100。反馈量 10（1 名独立用户）、共性广度 30（iOS、8.4.106、iPhone 机型、青海地区）、业务关键度 25（首次添加设备被阻断）。

2. Sensors 证据

  • 精确映射到 Logan 用户 16642968，14:26:06 至 14:51:00 完成 6 次 CodeScanning，说明用户持续重试扫码添加。
  • 用户在 14:52:24 才上报唯一一次 DeviceBind，场景为“设备列表扫码添加”，结果 is_success=0、error_code=-102。
  • 同一版本当天的两类扫码入口发生量较大，但不能直接当成功率使用：添加设备页面扫码添加 有 2,641 次设备绑定结果事件，其中成功 1,509、失败 1,132；设备列表扫码添加 有 1,816 次，其中成功 1,096、失败 720。一次添加流程可能产生多步事件，因此这里只用于表示面，不据此计算成功率。
  • Sensors 没有独立的“绑定结果轮询”事件，30200111 只存在于 Logan，当前埋点无法衡量旧随机码轮询造成的卡死时长，这是明确观测缺口。

3. Logan 关键日志

  • 反馈 ID：258878，Logan 文件 20f75b21-168e-4150-ae7e-c339580b4649.log.gz，共 14,368 行。
  • 14:37:02.987：首次轮询 GET /seetong-member-device/device/bind/result?devSn=&randCode=82785985&timeout=54，返回 200。
  • 14:39:01.208 至 14:40:24.709：同一 randCode=82785985 每约 3 秒重复轮询，持续返回 ret=30200111。知识库接口定义中，该错误码表示“绑定随机码不存在”。
  • 14:39:18.770：POST /seetong-member-device/device/bind/rand-code 返回 200，并在 14:39:19.094 使用新码 36930677 查询，接口返回 200。
  • 14:40:21.530：再次取得另一个新码 17205013，其查询也返回 200。
  • 14:40:24.709：旧码 82785985 仍继续返回 30200111。新旧轮询并存说明旧控制器或旧请求链没有被取消。
  • 14:52:24 最终一次 DeviceBind 返回 -102。这可能是后段网络失败，但无法解释前 3 分钟旧码不存在、新码已成功却仍被旧 timer 反复覆盖的现象。

4. 代码定位

  • 涉及模块：Seetong-App-iOS/Seetong5.0_ios/Seetong_tps/Classes/TPS/UIVC/VCList/APWifiSet。
  • WaitCfgViewController.m:85-90：页面加载时创建重复 timer，并立即用当前 self.randCode 开始查询绑定结果。
  • WaitCfgViewController.m:109-114：viewWillDisappear: 只移除通知，没有失效 bind_timer；重新进入或生成新码时，旧 timer 仍可存活。
  • WaitCfgViewController.m:655-682：queryBindResultWithRandCode 的 onFailure 每 3 秒继续递归调用自身，并原样复用闭包中的旧 randCode，没有区分 30200111、网络失败和正常“尚未绑定”。
  • CheckRegistCloudPaltformVC.m:436-460 与 DevAddStatusViewController.m:348-372 也分别维护独立轮询 timer 和查询闭包，代码没有统一的请求代次或随机码版本校验。
  • 调用链可归纳为：扫码解析 → 申请绑定随机码 → 进入等待配网页 → timer 或递归延迟查询 /device/bind/result → 随机码轮换或页面切换 → 旧闭包继续使用旧码 → 30200111 → 3 秒后再次使用旧码。
  • 修复锚点：WaitCfgViewController.m:86-90、:109-114、:655-682，以及所有 bind_timer 的创建与销毁位置。

5. 根因结论

  • 置信度：现象 🟢 强；旧随机码轮询与新一轮并发 🟢 强；最终 -102 与旧轮询的因果边界 🟡 中。
  • 一句话根因：添加设备流程没有为随机码建立单一 owner 和代次，页面离开或换码后旧 timer 未失效，onFailure 又无差别复用旧码，导致页面持续被“绑定随机码不存在”拖回失败态。
  • 明确不下的结论：不把本问题整体归为普遍网络问题。最终确实存在一次 -102，但旧码 30200111 连续重试是独立的客户端状态机缺陷。

6. 建议下一步

  • 分配给：iOS 设备添加流程负责人，代码历史锚点为谭伟。新建任务 T-20261022-170642-c470，状态 P1 / captured。
  • 为每次添加创建唯一 bindSessionId + randCodeGeneration，回调必须校验会话和代次，旧请求、旧 timer、旧页面回调一律丢弃。
  • 在 viewWillDisappear、返回、换码、重试和重进流程时统一停止旧轮询，由单一协调器管理全流程，避免多个控制器各自持有 timer。
  • 将 30200111 定义为不可原地重试状态：立即重新申请随机码一次；若新码仍不存在，则结束轮询并展示明确失败与重新开始入口。
  • 新增“申请随机码、开始轮询、停止轮询、换码、最终绑定结果、失败码、等待时长”埋点，并带 bindSessionId，用来识别同一用户是否同时存在多个轮询。
  • 回归覆盖返回后重进、扫码后停留超过 5 分钟、连续切换配网方式、取得新码时旧请求仍在途、网络中断后恢复，以及前后台切换各 20 次。

本期扫描全量

分类与处置反馈数反馈 ID 或说明
🟠 iOS 一键重置密码失败，进入问题 12258852、258853
🟠 iOS 扫码添加设备轮询旧随机码，进入问题 22258876、258878
🔁 HarmonyOS 1.1.2.3 视频、离线与回放同域问题，24 小时内已分析4258887、258875、258872、258845
🟡 跨版本回放单点反馈，缺少可归属的新证据3258854、258846、258839
🟡 设备离线、存储配置、硬件故障或信息不足4258877、258862、258837、258840
🟢 低信息文本、业务咨询或用户操作8258893、258882、258881、258880、258873、258863、258851、258848
已折叠 1 条普遍性网络问题（含 -102/-101/-1002 与中/英/俄/法/西/葡/土/阿/日多语言网络提示模板，如 Проверьте телефонную сеть、Please check your mobile network）；全量明细见同名 Markdown 知识库。
反馈接口返回 total=66 / fetched=66 / complete=true / pages=2。同一用户短时间重复提交不放大独立用户数。网络模板 43 条包含越南语等价提示。

心愿单与数据源状态

心愿单 ID平台与版本诉求价值判断
5446iOS / 8.3.14.3报警装置增加呼喊姓名后手机报警提示⭐⭐ 可增强看护场景的即时提醒，但需要明确触发规则、误报控制和呼叫通道
5445Android / 8.4.1.6查看去年的监控录像⭐⭐⭐ 对取证和长期归档有价值，需评估云存成本、设备存储上限、隐私与保留周期
  • 反馈平台：✅ 正常。total=66 / fetched=66 / complete=true / pages=2。
  • 心愿单：✅ 正常。total=5 / fetched=5 / complete=true。
  • Sensors：✅ 正常。已验证 iOS 版本实际字符串为 8.4.106，完成 ForgetPassword 与 DeviceBind 的用户级、错误码级和 7 天趋势查询。
  • Logan：✅ 两条核心问题均有可用日志。问题 1 直接解析出 30000126，问题 2 直接解析出旧码 30200111 与新码 200 的并发。
  • 代码仓：✅ Seetong-App-iOS 位于标准路径，当前分支 feature_v8.4.2，已完成调用链与 timer 生命周期定位。
  • 友盟：⏭️ 未调用。本期问题为账号流程与绑定状态机异常，不是崩溃或 ANR。
  • TAPD：⏭️ 未调用。已有任务账本可直接承载后续验证，不以历史 Bug 搜索替代当前根因证据。
  • 待补证：问题 1 需服务端确认 checkCode 的 TTL 与闪验 token 失效规则；问题 2 需复现新旧两个 timer 并存时的导航栈和控制器生命周期。

下一期 = 第249期 = 2026-10-23-H09.md（明天早上 09:00；窗口 今日 17:00～明日 09:00）

🗂️历史期次

查看全部历史期次（近 90 天）→

由 OpenClaw 统一报告渲染器生成 · 最新更新时间：2026-10-22 17:07 · 数据以同名 Markdown 原始报告为准