[Bug] 页面刷新后面板 dock 停止更新——新的 panel:true 围栏被持久化重放屏障静默拒绝

[letff]

摘要

页面刷新后，会话面板 dock 冻结在之前渲染的内容上。之后发送的 panel:true dsh-ui 围栏被静默丢弃：dock 不更新，浏览器控制台也没有任何报错或警告。清除插件的持久化状态（localStorage.removeItem('dsh.genui.panel')）后更新恢复，但下次刷新又复发。

环境

项目	值
dsh-genui	0.8.0（安装自 github:omdsh-dev/dsh-genui#main，client.js 构建于 2026-08-14）
DSH 运行时	@deepseek-ai/dsh 0.1.0-rc.6
浏览器	Google Chrome 151.0.7922.109（正式版本，64 位，Stable）
操作系统	Windows 11 21H2（Build 22000.2538）；DSH 服务端运行于 WSL2（Ubuntu 22.04）
安装方式	profile 依赖 "@omdsh-dev/dsh-genui": "github:omdsh-dev/dsh-genui#main"

复现步骤

1. 在会话中发送一个 panel:true 的 dsh-ui 围栏（任意 spec，如 badge + 按钮）。dock 正常渲染。✅
2. 再发送一个内容不同的 panel:true 围栏。dock 更新为第二个内容。✅
3. 刷新页面（F5）。
4. 刷新后发送第三个内容不同的 panel:true 围栏。dock 仍显示第 2 步的内容。 ❌ 控制台无任何输出。
5. 验证诊断的工作区：DevTools 执行 localStorage.removeItem('dsh.genui.panel') 后刷新，新围栏又能更新 dock——但下次刷新再次失效，循环往复。

期望行为

页面刷新后发送的新 panel:true 围栏应正常替换 dock 内容（与不刷新时行为一致）。

实际行为

dock 停留在旧快照上。旧按钮仍能触发 [genui-action]（旧 spec 仍然存活），而所有新 panel 围栏都被静默拒绝。无任何日志、无错误。

根因分析（已在 v0.8.0 client.js 代码中核实）

面板 store 在跨页面加载时启用了幂等/重放保护：

• an() 从 localStorage['dsh.genui.panel'] 恢复会话状态，并初始化 replayBarrier = 持久化的 maxSeenSeq。
• on() 拒绝任何满足 t.order[0] <= e.replayBarrier（以及 e.seen.has(sourceId)）的操作——返回 null 即静默拒绝。
• order[0] 是消息序号，由 DOM 通道（Bn() → i() → zn()）从宿主的 [data-chat-anchor-key] 属性推导。
• 刷新后历史消息重放能通过屏障（幂等，正常），但新消息也无法通过：其 anchor 序号没有超过恢复的屏障（或跨页面会话不满足单调递增比较）。cn() 返回 "idempotent"/"blocked"，围栏被丢弃且零诊断。
• 清除 localStorage 键会将 replayBarrier 重置为 -1，这正是第 5 步能恢复更新的原因——证实持久化屏障就是拦截点。

与 #1 属于同一类问题（DOM/fence 通道中静默 return、无诊断日志）。

影响

任何刷新过页面的用户都会得到冻结的面板 dock。唯一临时办法是手动清 localStorage，且每次刷新后都会再次失效——对刷新过的会话来说实际上是永久故障。

建议修复（任一）

1. 屏障语义：replayBarrier 不应拒绝「严格新于当前快照」的操作；排序应改用全局单调递增的消息 id（如服务端消息序号），而非 DOM anchor 序号。
2. 按页面会话隔离：新页面会话开始时重置 replayBarrier（或把屏障存到 sessionStorage 而非 localStorage），避免一次刷新毒化后续所有更新。
3. 诊断（最小改动）：在 on()/DOM 通道的每个静默拒绝路径加 console.warn（与 MacOS 下 Chrome 正常渲染但是 Safari JS报错无法正常使用 #1 的诉求一致），至少让这类失败可观测。

关联

• MacOS 下 Chrome 正常渲染但是 Safari JS报错无法正常使用 #1（Safari：[data-chat-anchor-key] 缺失时围栏被静默丢弃）——DOM 通道中同一类静默失败模式。
• 近期流式修复（33f3836、dce0c32）涉及围栏识别，建议顺带检查 anchor/序号的推导是否受其影响。

[letff]

已核实 #1 的修复（PR #2）未覆盖本问题，本 issue 仍然有效。

核实方法：将最新 main 的 lib/client.js 与修复前的版本逐函数对比，涉及重放屏障的全链路函数—— / / / / / ——两者完全一致； 持久化键与 语义均未变动。PR #2 的改动范围仅限 DOM 通道： 锚点降级链（data-chat-anchor-key → data-chat-flow-key/kind → 代码块自身）与 诊断日志。

两者根因不同：#1 是宿主行无锚点导致围栏不渲染（渲染通道），本 issue 是刷新后持久化重放屏障拒绝新 panel 更新（store 屏障）。

补充：0.8.1 的 诊断日志对我们有利——升级后复现本问题会在控制台直接可见，我们将升级到 0.8.1 复测后回报结果。

[letff]

0.8.1 复测与最小补丁实测结果（本问题确认存在，附已验证的修复方案）

复测（0.8.1，与 main 逐字节一致）：重启服务后发送全新内容的 panel:true 围栏 → dock 仍停留在刷新前的旧面板，新围栏被静默丢弃。问题在最新代码中确认复现。

诊断日志缺口：复现时控制台没有任何 前缀警告。PR #2 的 warnOnce 只覆盖 DOM 通道（无锚点/空 body/坏体），而本问题的拒绝发生在 store 屏障层（ 返回 null → 返回 idempotent/blocked），该路径仍无日志。

最小补丁实测（已验证有效）：将 中屏障的恢复逻辑从持久化值改为固定 -1：

- replayBarrier:t.maxSeenSeq??-1
+ replayBarrier:-1

仅此一行改动（保留 的页面内重放防护），刷新页面后发送新 panel 围栏，dock 恢复正常更新。已复测通过。

建议：正式修复可考虑 - 持久化时不再恢复 replayBarrier（改为每次页面加载归零，重放防护依赖 /），或 - 屏障存 并在页面加载时校验会话标识。附带建议：给 / 的每个拒绝分支补 诊断日志（与 #1 的诉求一致），此类失败目前完全不可观测。

[taekchef]

@letff 感谢两份核实和最小补丁实测，非常扎实。按流程先重新打开 issue，等你验证通过再关。

修复已合入 main（PR #5，0.8.2），根因比最小补丁挖得更深一层：屏障本身没错，错的是喂给它的序号。

根因确认：宿主 anchor key = conversationContextKey(kind, id) = ${kind长度}:${kind}${id}，assistant step 的 id 是 ${turn}:${step}（如 14:assistant-step3:0）。DOM 通道 anchorSeqOf 旧实现取 key 里第一个数字 = kind 名称长度常量 → 所有消息的 order[0] 相同 → 刷新后 replayBarrier = 持久化 maxSeenSeq = 该常量 → 新围栏 order[0] <= barrier 全被拒。

修复方式（与你的最小补丁方向不同，保留完整重放防护）：

• anchorSeqOf 改从 key 解析 <turn>:<step> → seq = turn*1000+step，随消息顺序严格单调。刷新后新消息 turn 必然大于持久化屏障 → 正常更新；历史重放（同 turn）依然被屏障正确杀死——你的最小补丁（replayBarrier: -1）会丢掉这层跨刷新重放防护（历史滚动回放旧面板会复活，正是 0.7.0 修过的 bug 类）。
• /panel 本地覆盖的 localBarrier 同样依赖该 seq，此前一次 /panel 也会冻结后续更新，同根因一并修复。
• 诊断（你的附带建议）：applyPanelOperation 的屏障拒绝分支补了一次性 console.warn（[genui] 面板操作被重放屏障拒绝（source …，order[0]=… ≤ replayBarrier …），每 source 每页面会话一条，历史重放不刷屏）。

验证：新增回归测试精确复现你的复现步骤（turn 2/3 面板 → 模拟刷新 → 重放保持旧快照 → turn 4 新围栏更新 dock），旧代码上该测试失败于 expected '面板B' to be '面板C'，与你描述的症状一字不差；全量 363 项 0 失败。

请你复测：升级到 main（或等 0.8.2 发布）后按原步骤：发 panel:true 围栏 → 刷新 → 再发新围栏，dock 应正常更新。如果还有问题，控制台现在会有 [genui] 前缀的屏障告警，发上来即可。验证通过回一声我们就关。

[letff]

@taekchef 已升级到 0.8.2（PR #5）并完成复测，验证通过，可以关闭本 issue。

复测过程：

1. 升级到 0.8.2（lockfile 锁定 f75f286，与 main 一致）后刷新页面；
2. 发送第一块 panel:true 围栏（基线）→ dock 正常显示；
3. 刷新页面；
4. 刷新后发送第二块新内容围栏 → dock 正常更新为第二块内容。

修复前同一步骤 dock 冻结在旧内容，现在完全正常。

感谢你的深入排查—— 取 anchor key 第一个数字（kind 长度常量）导致所有消息 order[0] 相同这个根因，比我的最小补丁挖得深得多； 的单调序号方案既修复了问题又保留了跨刷新重放防护（我最初的 补丁确实会丢掉这层防护，你指出的历史回放复活风险是对的）。新的 屏障拒绝诊断日志也让这类问题从此可观测。

也感谢 #1 的修复让 DOM 通道的静默失败可诊断。

再次感谢，issue 可以关闭了！

[taekchef]

@letff 感谢你反复核实 + 最小补丁实测 + 0.8.2 复测，这个 issue 的生命周期堪称协作范例 🙏 按约定验证通过，现在关闭。

复盘一下这次修复（PR #5，已含在 v0.8.4 发布里）：根因是 DOM 通道把 anchor key 的第一个数字当成消息序号，而那个数字其实是 kind 名长度常量，导致所有消息 order[0] 相同、刷新后全被重放屏障拦下。修复为 turn*1000+step 的单调序号，既解决刷新冻结，又保留了你最初最小补丁会丢掉的跨刷新重放防护；屏障拒绝路径也补了一次性诊断日志。

如果后续还遇到面板不更新的情况，控制台会有 [genui] 面板操作被重放屏障拒绝… 告警，把那条日志发上来即可。谢谢！