issue: Sending a message and quickly switching conversations causes chat corruption — message is overwritten onto the wrong conversation

快速结论：在 Open WebUI 中发送一条消息后立即切换到另一个对话，会导致后续 API 调用（占位消息创建、补全流式请求、历史更新）作用于错误的目标对话，造成消息丢失和历史记录损坏。优先建议升级到包含修复的版本（dev 分支或更高版本），并避免在消息发送完成前快速切换会话。

问题场景

用户在 Open WebUI（v0.8.12，Git Clone 安装）的聊天界面中，于 Mac 系统上使用以下操作过程触发：打开一个会话（Chat A）并输入一条消息，按下 Enter 发送后，立即在侧边栏中点击另一个会话（Chat B），此时 API 调用尚未完成。此操作会导致 Chat A 中刚发送的消息丢失，且 Chat B 的历史记录被覆盖或损坏（例如，Chat B 中出现不应有的消息或无法加载）。该问题在社区中已被确认（labels: bug, confirmed, confirmed issue），原始 issue #19225 和修复 PR #22146 均指向同一根因。

报错原文

When sending a message and INSTANTLY switching to another chat, it will CORRUPT and BREAK the chat you switch to
The chat switching TO is then completely broken, it will load and load and never finish loading.
Exporting and importing the chat also doesnt work. The chat itself becomes broken.
And sometimes the chat you switch FROM also becomes broken by doing this

原因分析

问题本质是前端状态竞争与异步操作上下文错位。发送消息时，请求最初绑定 Chat A 的会话 ID；但用户极快切换到 Chat B 后，前端的上下文（current chat state）更新为 Chat B。后续的异步 API 调用（包括创建占位消息、请求 /completions 流式接口、更新聊天历史）不再引用原始 Chat A 的 ID，而是错误地使用了 Chat B 的 ID。结果是：Chat A 的消息未被持久化，而 Chat B 的历史被覆盖，甚至导致 Chat B 自身的数据结构损坏（加载死循环）。修复 PR #22146 应是从前端状态管理或请求队列机制上解决了此竞态条件。

环境排查

Open WebUI 版本：v0.8.12 及更低版本受影响；建议确认当前版本是否已包含修复（检查当前运行版本是否为 dev 分支或后续正式版）。
安装方式：Git Clone（其他安装方式理论上有相同逻辑，但以 Git Clone 为主要复现环境）。
操作系统：Mac（不排除其他系统，但 Mac 是报告者的环境）。
浏览器：未指定，建议确认浏览器版本并测试能否复现。
后端：Ollama 版本未报告，但建议确认 Ollama 及 Open WebUI 均为最新。

解决步骤

优先尝试：升级到包含修复 PR #22146 的版本。根据 issue 反馈，该修复已合入 dev 分支，并预计在后续正式版中发布。如果使用 Git Clone，可以 pull dev 分支或等待下一个正式版标签后更新。
临时规避：在发送消息后，等待 API 调用完成（即消息显示在对话中且 LLM 开始或结束响应）再切换会话。避免“发送后立即点击另一个会话”的操作模式。
恢复损坏的聊天：如果聊天已经损坏（例如 Chat B 加载死循环），导出并重新导入聊天的功能在 issue 中被报告为无效。目前没有官方修复指导来“修复”已损坏的会话数据；建议先备份当前数据库（Open WebUI 默认使用 SQLite），然后尝试删除对应会话记录（操作前务必创建数据库备份）。或者如果数据允许，可以舍弃该损坏会话并新建。
检查前端和 API 网络状况：如果升级后偶尔仍复现，可查看浏览器控制台（Console）网络请求，确认切换会话时是否有请求被取消或发往错误 ID，确保没有额外的网络延迟导致竞争窗口扩大。

验证方法

升级到包含修复的版本后，重复步骤：在 Chat A 输入消息并发送，立即（最快速）切换到 Chat B。观察：Chat A 中消息应正确出现，Chat B 的历史不受影响，且 Chat B 能够正常加载和显示会话内容。多次快速切换不同会话（3-5 次）也应无损坏现象。可以在浏览器控制台查看网络请求，确认所有 API 调用的会话 ID 与原始发送时的会话一致。