如果一个对话发过截图并提示失败，切换其他对话后，每次切换到该对话都会弹这个提示

[Leonardoyi]

版本：0.1.0-rc.7

[ylwl1997]

这条 toast 会跟着会话一起回来，是因为失败的图片块写进了 session 日志：每次切回这条对话，UI 会把附件再提交一次，官方 API 再拒绝一次。

rc.7/rc.8 接 api.deepseek.com 时还没有可用的视觉端点——#3559 实测三个官方模型 ID 都是 HTTP 400: unknown variant 'image_url', expected 'text'。所以不是「切会话没清缓存」，是这条会话被一张发不出去的图钉住了。

目前能做的：

• 这条对话不要再切回去，新开会话继续聊（或归档）。失败 toast 没有单独的 dismiss 持久化。
• 官方 DeepSeek 路由先保持 inputModalities: [text]，不要为了贴图去开 [text, image]。
• 现在就要看图：换一个真正接受 image_url 的 provider，或走社区视觉桥（先转成文字再交给主模型）。

[weijiafu14]

@ylwl1997 的诊断是对的（失败的图片块写进了会话日志，每次切回去 UI 再提交一次、API 再拒一次）。补一条他没提到的：0.1.1 那条线上宿主改了这个行为。

我维护一个要同时兼容两代 DSH 的东西，所以有一条钉死这个不变量的契约测试。它观察到的是：

• 0.1.0-rc.8（你现在是 rc.7，同一代）：分发原样到达适配器，请求被拒绝 —— 就是你反复看到的那个 toast；
• 0.1.1 线：宿主自己的分发先解决模态不匹配，把图片块替换成一句显式的 [image omitted …]，然后照常发出去。是可见的降级，不是硬拒。

（测试不是按版本号分支的，是探测宿主 LlmAdapter 基类上有没有 prepareCall ——那正是变了的那道缝。）

如果确实是这个机制，升到 0.1.1 之后这条会话应该能继续用，代价是那张图对模型不可见（会看到占位说明，不会被静默丢掉）。

我没验证的部分，你先在会话副本上试再说：我的测试打的是分发层。你这个 toast 看起来是发送前的准入检查弹的，如果 DSH 那里还有一道独立的门，升级未必能完全解开。这两道门是不是同一道，我没单独测过。

在那之前 @ylwl1997 给的几条（新开会话、官方 DeepSeek 路由保持 inputModalities: [text]）是对的。

利益相关：我维护 pi2dsh。上面这条跟它无关，是宿主自己的行为，我只是因为要跨两代保持一致才把它测了出来。