bug: Long chat thread fragmented into uneven sections with a 3-day data gap (PGlite)

快速结论：该报错发生在 LobeChat 处理超长会话线程时，客户端与服务器端存在分页机制不一致，导致部分历史消息无法渲染或在本地缓存中出现数据缺失。优先排查是否触发了服务端 1,000 条消息的分页上限，以及是否存在未正确重建的压缩消息组。

适用环境：LobeChat 桌面客户端（Electron）v2.2.13，Windows 操作系统，连接官方云服务（Official Cloud）。

最快修复方案：暂无确认的一步修复方案。可优先尝试通过 DevTools 手动调用 messageService.getMessages 并传入 current: 1 或 current: 2 获取更早的分页数据，以确认服务端仍保留完整历史消息。

注意事项：当前解决方案均为推测性排查步骤，尚未经过 Issue 作者验证。修复可能涉及客户端代码层面的分页逻辑调整，普通用户难以直接修复。

问题场景

用户在使用 LobeChat 桌面客户端（Electron）连接官方云服务时，打开一个持续数周、消息量极大的会话线程（Topic ID: tpc_a6XzACx7MnLO）。线程中的历史消息被分割成不连续的多段，界面只显示底部较新的消息区域，较早的历史消息虽然在本地 IndexedDB 中仍然存在但不被渲染，且丢失了特定 3 天（8月1日至8月3日）的数据。

报错原文

bug: Long chat thread fragmented into uneven sections with a 3-day data gap (PGlite)

The app screen completely refuses to render the surviving top part.
The 3-day middle section (August 1st to August 3rd) is completely missing from both the UI window and the database script query.

原因分析

根据 Issue 中的调查，问题可能涉及以下原因：

可能原因一：客户端/服务端分页机制不匹配。服务端 MessageModel.query() 默认每页返回 1,000 条消息且按新到旧排序，而客户端 useFetchMessages 请求完整会话时未发送分页参数，因此服务端只返回最新约 1,000 条消息，客户端将这些消息视为完整历史。超长线程中超过该上限的历史消息在应用层面无法被访问。

可能原因二：压缩消息组未正确重建。会话中的消息可能被系统压缩成 summary block（用户确认 AI 模型的上下文窗口顶部仍能看到压缩摘要块）。压缩组内的消息在基础查询中被单独排除，若重建过程出现问题，这些消息会从查询结果和缓存中消失。

可能原因三：同步失败未被重试。如果云端到本地的数据同步在某些时间点静默失败，LobeChat 的 SWR 层虽然会记录失败日志，但不会通过持久化队列进行重试，导致该时间段的消息从未写入本地缓存。

环境排查

LobeChat 版本：v2.2.13
客户端类型：Desktop App（Electron，内置 Chromium/Electron 引擎）
操作系统：Windows
部署平台：官方云服务（Official Cloud）
相关依赖：需要确认 IndexedDB 中的消息数据完整性，以及是否存在非空的 messageGroupId 字段

解决步骤

打开 LobeChat 桌面客户端的 DevTools（开发者工具），进入 Console 控制台。
手动调用 messageService.getMessages，传入 current: 1 或 current: 2 获取更早分页的数据，确认这些历史消息在服务端是否仍然存在。
查询该 Topic ID 对应的 messageGroups，确认 8 月 1 日至 8 月 3 日期间的消息是否被归类到某个压缩组（compression group）中。
检查 8 月 1 日至 8 月 3 日时间窗口内是否存在 messageGroupId 非空的消息记录。
若确认消息存在于服务端但客户端无法渲染，可尝试清理本地 IndexedDB 缓存后重新同步，观察问题是否复现。

验证方法

通过 DevTools 确认服务端仍能通过分页查询返回缺失的历史消息，且这些消息在数据库中存在。若问题确实由分页上限导致，更换到较短会话线程或减少单线程消息量后应不再出现历史消息消失的情况。若 8 月 1 日至 8 月 3 日的数据确认在服务端和本地均不存在，则说明该时间段的数据已从云端丢失，无法恢复。