修复：无效 session 路由导致会话切换卡住

[Kizunad]

问题概述

当 URL 中包含当前目录下不存在的 session id 时，UI 在切换会话过程中会出现“卡住/假死”的体验。日志常见交替为 switch:fetch-session 与 switch:use-cached，且无效 session 请求返回 404。

复现步骤

1. 打开类似 #/session/<invalid-session-id>?dir=/workspace/<project> 的链接
2. 确认该 session id 在当前目录下不存在（GET /session/{id} 或消息接口返回 404）
3. 通过侧边栏 / toast / 通知切换会话，或触发 SSE 重连
4. 观察到会话切换反复抖动，界面表现为卡住

根因分析

• 路由层会接受任意 #/session/{id}，没有先做有效性校验
• 会话加载失败时仅设置 loadState=error，没有清理无效路由
• 无效 session id 持续留在 hash 中，并可被多个入口再次写回
• 导致同一个无效 id 被反复请求，触发路由/状态来回切换

已实现修复方案

1）会话加载错误分类

文件：src/hooks/useSessionManager.ts

• 扩展 onError 回调参数，增加元信息：{ sessionId, reason }
• 识别 not found 类错误（404、not_found、Session not found）并标记为 reason: 'session_not_found'

2）无效 session 的路由安全回退

文件：src/hooks/useChatSession.ts

• 在 useSessionManager 接入 onError
• 对“当前路由会话”的 session_not_found 执行兜底：
  • messageStore.clearSession(sessionId)
  • resetPermissions()
  • resetPendingRequests()
  • replaceSession(null)（清理坏 session id，且不新增历史记录）

该方案可避免过期请求误伤新会话，并让 UI 立刻恢复可用。

为什么使用 replaceSession(null)

replaceSession(null) 使用 history.replaceState，会直接替换当前历史项并移除坏路由，不会额外污染浏览器历史；在此错误兜底场景下比 hash push 更稳妥。

验证结果

• 修改文件 LSP 诊断：无 error
• Typecheck：通过
• Tests：通过（31 files / 60 tests）
• Build：通过

备注

• 当前仓库里存在的 lint warning 为既有问题，本次修复未新增 lint error
• 本 Issue 仅跟踪“无效 session 路由导致卡住”问题，不涉及模型/Provider 配置问题

[lehhair]

好像没能复现出卡住

[Kizunad]

补充说明一下，我这边想表达的更接近一个“边界情况提醒”，不一定每次都稳定表现为完全卡死。

我观察到的点是：

• 如果 URL 里带了一个当前目录下不存在的 session id
• 且对应请求返回 404 / not_found
• 前端这时仍会停留在这个无效的 #/session/<id> 路由上

在这个前提下，如果后面再经过侧边栏切换、浏览器前进后退、通知 / toast 跳转等路径，就有机会反复命中这个坏 session，表现为会话切换抖动，体验上像“卡住”。

所以这里先作为一个现象提醒留档：
当前 route 对应 session 明确不存在时，前端似乎不会自动退出这个无效 session 路由。

如果你那边稳定无法复现，也没关系，就当做一个排查线索保留在这里。

[Kizunad]

gpt写的 :)

[lehhair]

补充说明一下，我这边想表达的更接近一个“边界情况提醒”，不一定每次都稳定表现为完全卡死。

我观察到的点是：

• 如果 URL 里带了一个当前目录下不存在的 session id
• 且对应请求返回 404 / not_found
• 前端这时仍会停留在这个无效的 #/session/<id> 路由上

在这个前提下，如果后面再经过侧边栏切换、浏览器前进后退、通知 / toast 跳转等路径，就有机会反复命中这个坏 session，表现为会话切换抖动，体验上像“卡住”。

所以这里先作为一个现象提醒留档： 当前 route 对应 session 明确不存在时，前端似乎不会自动退出这个无效 session 路由。

如果你那边稳定无法复现，也没关系，就当做一个排查线索保留在这里。

我确实这样操作了，并没有稳定复现，那这个issue就开着吧，等后面有人可以稳定复现，再做修复，感谢反馈