Skip to content

(sidebar): recount a session's messages when its transcript grows (#1017) - #1019

Merged
devsuitup merged 5 commits into
mainfrom
wt/1017
Nov 3, 2026
Merged

devsuitup merged 5 commits into
mainfrom
wt/1017

Conversation

@devsuitup

Copy link
Copy Markdown
Owner

Closes #1017.

During the v0.0.103 live retest, a session that grew kept showing its first message count ("2 msgs"), even after a full reload. An incremental refresh merged the cached row and never recounted.

How the fix works:

  • src/main/session-index/message-count.js keeps a small per-transcript count index (bytes covered, count, file stamp). It is persisted in a new session_cache.messageCountIndex column.
  • On an incremental refresh, only the appended bytes are counted, using the same isCountedMessage rule as a full read.
  • If the file was rewritten or shrank, or the index does not match, the refresh falls back to a full read. A merged bridge member also triggers a full read.
  • The 30 s activity-notify throttle is unchanged.

Tests:

  • test/session-cache-message-count-1017.test.js covers parent and subagent transcripts, a large file, a partial tail, a rewrite, and the migration. It was red before the fix: expected 4, got 2.
  • Four existing tests had their counts updated to the corrected numbers.
  • Under Node 22, all of these pass under both TMP spellings.
  • Under Node 20 the new test is skipped: it uses the node:sqlite store fixture, like the other store tests.
  • Lint is clean.

Note: #865 also adds columns in session-index-store.js. Whichever PR lands second will need a trivial merge there.

Harness-Claim: true
Agent: switchboard-dev
Host: ANCHOR
Base-Ref: origin/main
Base-SHA: abd011b
Claimed-At: 2026-11-03T13:34:15.3826181Z
Nonce: 7195b284bae36377
)

An incremental refresh merged the cached row and kept its old messageCount,
so a growing conversation showed the same count forever, even after a reload.
Persist a small count index per transcript and count only the appended lines
on an incremental refresh, falling back to a full read when the file was
rewritten or the index does not match.
Remote mirrors grow by copy, append and rename, so a new inode made every
fetch recount the whole transcript on the main thread. For remote folders,
reuse the count cursor when the head and tail witnesses still match. Treat
bridge rows as filtered, fall back to the header path when a full read
fails, and share one stat in readSessionFile.
@devsuitup
devsuitup merged commit e0f144b into main Nov 3, 2026
11 checks passed
@devsuitup
devsuitup deleted the wt/1017 branch November 3, 2026 21:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

(sidebar): a session's message count is never recounted after its transcript grows

1 participant