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

快速结论：该问题出现在管理员通过 Admin Panel → Users → Chats 打开他人共享会话（路由为 /s/{chat_id}）时：向上滚动阅读历史消息会被不断拉回底部，同时浏览器反复请求 /api/v1/chats/share/{id}。优先排查前端加载逻辑是否被聊天记录的响应式更新反复触发，其次关注服务端连接池与文件描述符耗尽风险。

适用环境：Open WebUI v0.12.3（Docker Compose 部署，带本地定制）；PostgreSQL 数据库；Windows 11；Google Chrome 155.0.8059.80。Issue 讨论中另有维护者与复现者在最新 dev 分支、Firefox 下复现。未提供 Ollama 版本信息。

最快修复方案：暂无确认的一步修复方案。根因修复指向 PR #32725（Issue 关闭后由该 PR 跟进），需等待该合并版本发布；在修复发布前，可优先尝试设置 DATABASE_POOL_SIZE 为适中值（如 100）并/或提高容器的 nofile ulimit，以缓解服务端资源耗尽。

注意事项：限制连接池或提高 ulimit 只是缓解服务端副作用，并不会阻止前端反复请求和视口回跳本身；该缓解方案来自 Issue 评论中的分析，未经完整回归验证。不要在未评估负载的情况下随意放开 nofile 上限。

问题场景

在 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 版本要求，这些项目无需作为排查前提。

解决步骤

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

验证方法

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