Bug: Large paste into Notes causes WebSocket to reconnect and doesn’t save the notes

快速结论：在 Open WebUI 的 Notes 中粘贴较大文本（约 150 KB 以上即可能触发）时，协作编辑的 WebSocket 会因单条消息超过 Socket.IO 默认的 max_http_buffer_size（1,000,000 字节）而断开重连，笔记看起来接受了粘贴内容，但实际未写入数据库，重新打开后内容丢失。优先排查 Notes 中的大文本粘贴场景，以及服务端 Socket.IO 缓冲区上限。

适用环境：Open WebUI v0.9.5（Docker 安装）；在最新 main（v0.9.6）与 dev 上也可复现。操作系统 Debian Trixie，浏览器 Brave；报告者另在 Chrome DevTools 中观察到约 1.1 MB 的二进制 WebSocket 消息。其余环境项 Issue 未提供。

最快修复方案：暂无确认的一步修复方案。Issue 中已验证的规避手段是：粘贴时控制单次内容体积（测试数据显示 16,776 字节可正常保存，150,025 字节即丢失），或分多次、小块粘贴以避开单条 WebSocket 消息超限。

注意事项：Issue 关闭时未提供官方修复补丁或配置项，以上仅为已验证的规避方式，并非根因修复。150,025 字节这一档的测试中，重连后编辑器会把整个文档再发一次，但因为没有附带 Markdown/HTML/编辑器 JSON 副本，内容进入了实时文档却没有落库，所以“界面显示正常”并不代表已保存。

问题场景

在 Open WebUI 的 Notes（笔记）中粘贴一段较大的文本时触发。用户观察到前端短暂提示 connection lost / reconnecting / reconnected，随后可能出现反复重连；粘贴的文本一开始显示在编辑器里，离开笔记再打开后内容消失，且浏览器控制台、应用日志、Nginx 日志中都没有明确的保存失败报错。报告者在 Docker 部署的 v0.9.5 上复现，并在 v0.9.6 与 dev 分支上确认仍存在，只是新版本不再弹出断连与重连的提示。

报错原文

Bug: Large paste into Notes causes WebSocket to reconnect and doesn't save the notes

Socket undefined disconnected due to transport close
Object { description: "websocket connection closed", context: close }
GET ws://localhost:5173/ws/socket.io/?EIO=4&transport=websocket [HTTP/1.1 101 Switching Protocols 1ms]
connected bPQu-K_abLxxwCTgAAA1

saved md length: 0

Nginx 侧仅出现正常的握手记录：

GET /ws/socket.io/?EIO=4&transport=websocket HTTP/1.1" 101

Open WebUI 服务端日志只有加入/离开文档的记录，没有保存错误：

open_webui.socket.main:ydoc_document_join - User ... joining document note:...
open_webui.socket.main:ydoc_document_join - User ... successfully joined document note:...
open_webui.socket.main:yjs_document_leave - User ... leaving document note:...
open_webui.socket.main:yjs_document_leave - Cleaning up document note:... as no users are left

原因分析

根据 Issue 中报告者的代码分析，可能原因是：Notes 的协作编辑走 Yjs + WebSocket，每次编辑通过 ydoc:document:update 发送，负载中 Yjs update 以 JSON 数字数组（Array.from(update)）形式传输，同时还会附上整份笔记内容的 Markdown、HTML 与编辑器 JSON 副本。服务端 Socket.IO 使用 python-engineio 默认的 max_http_buffer_size 1,000,000 字节，单条消息一旦超过该上限，连接就会被关闭。

数字数组的体积约为 Yjs update 的 3.5 倍，而 Yjs update 本身又大于原始文本，因此在文本还没达到 1 MB 之前，消息就可能已经超限。重连之后编辑器会把整个文档作为一条 update 再发一次，但这条消息不带内容副本；服务端只有收到内容副本时才把笔记写入数据库。于是出现两种表现：

重发消息仍低于上限时（如 150,025 字节的粘贴），文本进入实时文档，但从未落库，重载后为空；
重发消息同样超限时（200,056 字节及以上），连接再次关闭，形成反复重连的循环。

以上均为报告者的分析结论，Issue 中未见官方确认的根因说明。

环境排查

确认 Open WebUI 版本：报告使用 v0.9.5，并在 v0.9.6（main）与 dev 上复现。
确认安装方式：Docker。
确认操作系统：Debian Trixie。
确认浏览器：Brave；可在 Chrome DevTools 的 WebSocket 帧中查看单条消息大小。
检查服务端 Socket.IO 的 max_http_buffer_size 是否为 python-engineio 默认值（1,000,000 字节），例如通过代理层或启动参数是否覆盖该值。
检查 Nginx 等反向代理是否对 WebSocket 帧或消息大小设置了额外限制。
Issue 未涉及 Ollama 版本、Python、CUDA、PyTorch 或显卡信息，无需按这些项排查。

解决步骤

先用小文本验证基本保存链路是否正常：粘贴约 200 行（16,776 字节）的文本，等待片刻后重载笔记，确认内容仍在。
再用大文本复现问题：粘贴约 1,772 行（150,025 字节）的文本，重载笔记。若内容为空，说明命中了该问题路径。
在笔记仍打开、尚未重载时，可在浏览器控制台读取服务端已保存的内容长度，判断是否真的落库（Issue 中提供的检查脚本）：

const id = location.pathname.split('/').pop();
const n = await (await fetch(`/api/v1/notes/${id}`, { headers: { Authorization: `Bearer ${localStorage.token}` } })).json();
console.log('saved md length:', (n.data?.content?.md ?? '').length);

若输出为 saved md length: 0，说明粘贴内容没有写入数据库，与 Issue 描述一致。
可优先尝试的规避方式：避免一次性粘贴大段文本，改为分多次、每次控制在 100 KB 以下的块粘贴；或在粘贴后逐段确认并等待，再进行下一次粘贴。
如需从缓冲区角度处理，可尝试调整服务端 Socket.IO 的 max_http_buffer_size，但该做法未在 Issue 中被验证，且无法解决“重连后重发消息不带内容副本导致不落库”的问题，因此仅作为排查方向。
关注 Issue 后续修复：报告者建议分两步解决，一是让 UI 正确反映后端保存状态，二是修复笔记保存（例如分块发送）。在官方修复发布前，Notes 中的大文本粘贴仍有数据丢失风险。

验证方法

粘贴文本后，先不要离开笔记，用上面的控制台脚本读取 saved md length：数值与粘贴内容的 Markdown 长度一致，才说明已持久化。随后离开笔记并重新打开，确认内容完整保留、没有出现 connection lost / reconnecting 提示，也未出现反复重连，即可认为该场景下保存正常。若重载后内容为空或仍反复重连，说明问题未解决。