Summary
/continue (list mode) silently omits long sessions from the session list. A session whose log file has its first real user prompt beyond the 32KB head window gets an empty preview and is filtered out entirely, even though the session is valid and recent.
Root cause
In frontends/continue_cmd.py, _preview_from_file() reads only two fixed windows:
_PREVIEW_WIN = 32 * 1024 # line 180
...
head = fh.read(_PREVIEW_WIN) # first 32KB
fh.seek(-_PREVIEW_WIN, 2); tail = fh.read() # last 32KB
Preview resolution order:
- last
<summary> in the tail window
- last real user prompt in tail, then head
- otherwise
return '' → list_sessions() filters the session out
For a long, tool-heavy session (e.g. a 5.5MB log where the first ~54KB consists of tool_result prompts from an initial tool-call loop), the first actual user text prompt sits past the 32KB head window, and the tail window contains no <summary> and no user prompt either. Both lookups return empty → '' → session disappears from /continue.
Regression note: _PREVIEW_WIN was reduced from 1MB to 32KB (commit 2923212e, for preview latency), which made this window-size blind spot much more likely.
Repro
- Have any session whose
temp/model_responses/model_responses_*.txt is >64KB with the first real user prompt beyond the first 32KB (common with long initial tool-call loops).
- Run
/continue → the session is missing from the list.
- The session file itself is intact; only the preview/list is affected.
Impact
- Users cannot see/resume recent sessions — they appear to "vanish" even though the logs exist.
- Affects every long session with a heavy tool-call prefix; no error is surfaced.
Suggested fix (verified locally)
- Raise
_PREVIEW_WIN from 32 * 1024 to 128 * 1024 (covers the common head-anchored case).
- Add a fallback in
_preview_from_file(): when both head+tail windows yield nothing and sz > _PREVIEW_WIN * 2, progressively scan the file in _PREVIEW_WIN chunks (bounded by _GREP_WIN, currently 1MB) to find the first real user prompt.
With this fix, the previously-dropped 5.5MB session now previews correctly ("接下来使用最新的 focr 继续完成之前剩余 PDF 入库工作"), all 10 local logs get previews, and list_sessions() went from 8 → 10 entries with no measurable latency (≈0.10s).
Happy to open a PR with the patch if maintainers agree with the approach.
Summary
/continue(list mode) silently omits long sessions from the session list. A session whose log file has its first real user prompt beyond the 32KB head window gets an empty preview and is filtered out entirely, even though the session is valid and recent.Root cause
In
frontends/continue_cmd.py,_preview_from_file()reads only two fixed windows:Preview resolution order:
<summary>in the tail windowreturn ''→list_sessions()filters the session outFor a long, tool-heavy session (e.g. a 5.5MB log where the first ~54KB consists of
tool_resultprompts from an initial tool-call loop), the first actual user text prompt sits past the 32KB head window, and the tail window contains no<summary>and no user prompt either. Both lookups return empty →''→ session disappears from/continue.Regression note:
_PREVIEW_WINwas reduced from1MBto32KB(commit2923212e, for preview latency), which made this window-size blind spot much more likely.Repro
temp/model_responses/model_responses_*.txtis >64KB with the first realuserprompt beyond the first 32KB (common with long initial tool-call loops)./continue→ the session is missing from the list.Impact
Suggested fix (verified locally)
_PREVIEW_WINfrom32 * 1024to128 * 1024(covers the common head-anchored case)._preview_from_file(): when both head+tail windows yield nothing andsz > _PREVIEW_WIN * 2, progressively scan the file in_PREVIEW_WINchunks (bounded by_GREP_WIN, currently 1MB) to find the first real user prompt.With this fix, the previously-dropped 5.5MB session now previews correctly ("接下来使用最新的 focr 继续完成之前剩余 PDF 入库工作"), all 10 local logs get previews, and
list_sessions()went from 8 → 10 entries with no measurable latency (≈0.10s).Happy to open a PR with the patch if maintainers agree with the approach.