code-yeongyu / code-yeongyu/senpi
bug(coding-agent): post-compaction entry counting re-materializes the full JSONL history on the settled path
- Dominant language
- TypeScript
- Stars
- 429
- Forks
- 98
- Avg merge
- 5h 3m
- Merged PRs (30d)
- 526
Description
## Summary
packages/coding-agent/src/core/session-manager.ts:
- entriesCache (line 882) is invalidated by mutationCount bumps, but after _trimMirrorAfterCompaction (lines 1381-1404) any count/hasEntries query that goes through getEntries (lines 1651-1656) re-materializes the full (trimmed) entry list from disk — and embedders call exactly such a check on every agent_settled (e.g. the omo memory wiring-context hasEntries probe), turning each settled turn into a full JSONL reparse: peak memory + CPU on long sessions.
Open PR #1635 adds an O(1) getEntryCount() for three UI cadence reads. This issue covers the remaining gap: an O(1) hasEntries/count path for embedder settled-time checks, coordinated with #1635 so the two do not duplicate counters.
## Context
Root-caused during a profiling investigation of a long-lived macOS host (M4 Pro, 64 GB) running ~28 concurrent senpi/omo sessions for several days. Symptoms: load average ~150 with ~50% CPU utilization (threads blocked on swap I/O), 20 GB swap in use, 61 ppid=1 orphan processes (~2.1 GB, including vite dev servers up to 3.1 GB compressed, dev-runner and vp trees), and 12-14 zombies whose parents are live TUI main processes. All file:line references are against main (b19491745). Raw profiling evidence held locally.
## Expected (ideal state)
Count/hasEntries queries are O(1) before and after compaction; the settled-time embedder path never reparses the JSONL; behavior of explicit history retrieval is unchanged.
## Acceptance criteria
- Tests: after a compaction trim, getEntryCount/hasEntries answers without reading the session file (fs spy); counts stay correct across append/load/reset/trim.
- Coordinated with PR #1635 (shared counter or explicit boundary).
## Related
- #1635 (open PR, same counter theme)
- #1461 (compaction memory growth)
Contributor guide
Research direction
Start in packages/coding-agent/src/core/session-manager.ts, reading entriesCache, _trimMirrorAfterCompaction, and getEntries around the cited lines. Coordinate the counter boundary with PR #1635, then verify with an fs spy that post-compaction getEntryCount/hasEntries avoids reading the session file and remains correct across append, load, reset, and trim.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 58/100