AskaEth
9980fb2b28
## S2 —— 次级会话没有握手 history 这第二条安全网 - 新增纯判据 `ui/chat/ReconnectPull.kt`：连接恢复那一刻该补哪一段 （Forward / FirstPage / Nothing）。判据只看四样：会话 id、首屏状态、掉线游标、 「本端已知它没了」。 - `ChatViewModel`：把 init 那次首屏 `loadLatest` 提成 `loadFirstPage()`，init 与补拉 **共用一份代码**（补出来的结果必须与首屏逐字段同形）；新增 `FirstPageState` 作为判据输入。 为什么这么定： - **为什么不是照抄主会话的 history**：服务端固定回放主会话（`ws_hub_conn.go`），要它回放 次级会话就是改契约面。次级走的是本项目已有的那条 REST 口径（拉最新一页）。 - **为什么用「首屏从没成功过」而不是「本端有没有数据」**：服务端真的没有消息时列表**也是空的**， 拿空列表当判据会让每一个空次级会话在每次重连都被整表重拉 —— 那正是 S4/S7 这一类问题的成因。 - **为什么 Loading 不算失败**：首屏还在飞时再发一次同样的请求会与它抢跑，还会改掉 「history 帧一到就 loading=false」那段时序（S3 本轮**一个字节都不动**）。 - **为什么主会话排除在外**：它有 history 兜底，在那里再补一条 REST 就是给同一件事造第二套口径。 主会话的兜底行为因此**逐字不变**（有洞走 Forward，其余 Nothing）。 - 补拉那一次把 `loading` 翻回真：屏幕上原本是「还没有消息」停在原地，如实应该是「加载中…」。 ## S7 ① —— 注定 404 的补拉不再发生 - 新增 `core/session/GoneSessions.kt`（进程级、**不持久化**、登出/换账号时清空）：本端已知 「服务端没有这个会话」的 id 集合。写入口是 `SessionsViewModel.deleteSession` 成功那一刻 （本端唯一的删除入口），读入口是**每一个** `ChatViewModel`。 - 判据第 1 条：已知它没了 ⇒ 什么都不发。于是本地删过的会话从此**零次**注定失败的往返； 已经 404 过的会话从「每次重连各撞一次」收敛成**恰好一次**（`sessionGone` 同时成为补拉的闸）。 ## S7 ② —— sessionGone 的出路不再依赖网络 那个位的消费者**一直都在**（`ChatScreen` 按它触发的 `LaunchedEffect` → `ChatHomeScreen` 的 `onSessionGone`：一句如实告知 + 带回主会话），所以本轮补的是它真正的缺口 —— 原来只靠 `refresh` **成功**之后的 `resolveActiveSession` 回落（拉失败、或列表为空时刻意不回落 ⇒ 什么都不动）。 于是「已切回主会话」在网络不稳 / 服务端抖一下时是一句**做不到的话**，用户被留在已经没了的会话上、 没有任何出路。现在先在本端 `select(主会话)`（与用户点抽屉里那一行走的是**同一条**路，不另造机制）， `refresh` 退回本职：与服务端对齐、把抽屉里那条去掉。 ## 未做 / 未验 - **没有真机验收**（任务书禁碰 adb）：S2 的「连接恢复后次级会话自己补上」只有纯判据单测。 - 「REST 首屏失败、但 WS 从头到尾没断（因此没有任何状态变化可挂）」这一格**不在本轮范围内**， 仍是已知缺口。 - 全程未碰 S3、主会话兜底与游标口径、W48 的 VM key、W49 的节流判据、W50 的主动消息消费路径。