issue: shared chat pages (/s/) reload endlessly and jump back to the bottom since v0.12.3

问题场景

在 Open WebUI v0.12.3 中，先以普通非管理员账号创建一段足够长、需要滚动才能看完的会话（复现时约 80 条已完成消息），再以管理员身份进入 Admin Panel → Users，点击该用户的 Chats，打开其已完成的会话，路由为 /s/{chat_id}。此时向上滚动几次并在每次滚动间稍作停留，视口会反复跳回底部。

根据 Issue 中给出的 server-side 说明，单个打开的 /s/{id} 页面每轮循环会触发多个请求：/api/v1/users/user/settings、/api/models、/api/v1/users/{id}/info、/api/v1/chats/share/{id}，一分钟内可达数百次请求。在默认 SQLite 配置下，这种请求风暴可能拖垮整个实例，而不仅是当前标签页。

报错原文

issue: shared chat pages (/s/) reload endlessly and jump back to the bottom since v0.12.3

浏览器控制台未发现报错，服务端也未定位到异常堆栈；主要证据是 DevTools → Network 中反复出现的 /api/v1/chats/share/{id} 请求，以及视口复位。本地复现测试期间共观察到 22 次对该接口的请求。

若连接池被请求风暴撑大并耗尽文件描述符，其他用户的请求会失败并出现：

OSError: [Errno 24] Too many open files

原因分析

可能原因（Issue 中给出调查方向）：src/routes/s/[id]/+page.svelte 中的响应式加载逻辑存在问题——聊天记录（chat history）更新会再次触发同一会话的加载，进而引发滚动到底部的行为，形成“加载 → 更新 → 再加载”的循环，导致视口不断回跳。

可能原因（服务端副作用）：默认 SQLite 配置下，异步引擎在未设置 DATABASE_POOL_SIZE 时 pool_size 默认为 512（见 backend/open_webui/internal/db.py）。每个池化的 aiosqlite 连接都会占用数据库文件及其 -wal 文件的文件描述符和一个工作线程，且连接池在流量尖峰后不会自动收缩。在请求风暴下连接池持续增长，遇到常见的 nofile 上限 1024 时进程文件描述符耗尽，其他用户请求（包括连接 Ollama 和提供前端静态资源）随之失败，但进程本身仍在运行。

环境排查

• 确认 Open WebUI 版本是否为 v0.12.3 或相近版本，并确认是否已在最新 dev 分支复现。
• 确认部署方式为 Docker / Docker Compose，并记录数据库类型（Issue 中复现环境为 PostgreSQL，服务端副作用分析针对默认 SQLite）。
• 检查是否设置了 DATABASE_POOL_SIZE；未设置时 SQLite 异步引擎会使用默认 pool_size=512。
• 检查容器或宿主机的 nofile ulimit 值（常见默认为 1024）。
• 在浏览器 DevTools → Network 中确认是否持续出现 /api/v1/chats/share/{id}、/api/models 等重复请求。
• 检查服务端日志中是否出现 OSError: [Errno 24] Too many open files 或其他用户请求失败的情况。
• Issue 未提供明确的 Python、CUDA、PyTorch、显卡或 Ollama 版本要求，这些项目无需作为排查前提。

解决步骤

1. 先确认症状：以管理员身份从 Admin Panel → Users → Chats 打开普通用户的已完成长会话，向上滚动。若视口反复回到底部，同时在 Network 面板看到重复的 /api/v1/chats/share/{id} 请求，即可确认命中该问题。
2. 等待根因修复发布：Issue 中给出的根因修复为 PR #32725，Issue 本身已关闭；请关注该 PR 合并后对应的正式版本并升级，这是唯一指向根因的处理方式。
3. 缓解服务端资源耗尽（可优先尝试）：在修复版本可升级前，将 DATABASE_POOL_SIZE 设为适中值（例如 100）。Issue 评论指出，一旦连接池被限制，同一循环便不再耗尽文件描述符。
4. 辅助缓解（可优先尝试）：提高容器或进程的 nofile ulimit，以降低文件描述符触顶的概率。建议与上一步搭配使用，而非单独依赖。
5. 减少影响面：在修复发布前，避免长时间保持多个 /s/{id} 标签页打开，以降低请求量叠加对实例的冲击。

验证方法

以管理员身份重新打开该用户的 /s/{chat_id} 长会话，向上滚动并在多次滚动之间稍作停留：视口应停留在阅读位置，不再反复跳回底部；DevTools → Network 中不应再出现循环往复的 /api/v1/chats/share/{id} 请求。同时观察服务端日志，确认未出现 OSError: [Errno 24] Too many open files，其他用户的请求与 Ollama 连接、前端静态资源加载均正常。

参考来源

open-webui/open-webui #32657

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。