1.8 KiB
1.8 KiB
Agent Note: 大规模历史记录的溯源信息通过扫描处理，不做参数展开
Status: implemented Archived: 2026-08-22
English | 中文
问题
一条已定稿的 assistant 消息可以通过 sourceEventSeqs 引用数十万个流式分片。历史记录分页使用 Math.min(event.seq, ...sourceEventSeqs) 查找消息组的首个事件，因此，有效会话可能超出 JavaScript 引擎的函数参数数量上限，导致 session.history 以 HTTP 500 失败。
决策
分页逻辑逐项扫描 sourceEventSeqs，每次使用一个元素更新最早的序号。该算法的复杂度相对溯源信息规模仍为线性，并保留现有的页面边界：页面起点位于其所含最早消息的所有已记录来源之前。
回归测试会拒绝以多个参数调用取最小值的做法，并验证每个溯源事件都会与其已定稿消息保留在同一页中。这既覆盖了故障机制，也避免默认测试套件分配生产规模的分片流。
考虑过的替代方案
- 提高 JavaScript 栈或参数上限：不予采纳，因为该上限取决于引擎和部署环境，而且数组展开仍会让有效历史记录受制于无关的运行时上限。
- 在分页时截断
sourceEventSeqs：不予采纳，因为这可能会从消息中间切分页面，破坏回放分组。 - 在提供方边界限制流式分片数量：不予采纳，因为提供方可能会合理地产生长流，而分页必须处理每一种有效的会话表示。
后果
- 大型溯源数组不再仅因长度而使历史记录分页抛出异常。
- 分页语义与协议响应保持不变。
- 本决策不限制历史记录页面的字节大小，也不限制浏览器回放该页面的开销；这两项性能问题仍与服务端调用栈故障分开处理。