(sidebar): exclude subagents from project-level archive-all - #149
Merged
Conversation
buildProjectsFromCache groups every session_cache row by projectPath, subagent rows included, so project.sessions is a flat list of parents and children. The project header's "Archive all sessions" button treated it as top-level only: it counted subagents in its confirmation prompt, archived each subagent transcript so it disappeared from under its parent, and called stopSession on any subagent id present in activePtyIds. This also makes the bulk button consistent with the per-session archive button, which never touched children. Not archiving the children exposes a latent hole in processProjectSessions' skip guard: the archived parents are gone from project.sessions but the subagents remain, so filtered is empty while the array is not, and the whole project dropped out of the default view — header and orphan bucket alike, the latter living past the render loop's continue. Keep the project when unarchived subagents remain and no filter is active, so the existing orphan bucket renders them. The status bar's session total had the same flat-list defect and disagreed with the stats panel, which counts WHERE parentSessionId IS NULL.
devsuitup
force-pushed
the
fix/project-archive-all-subagents
branch
from
August 23, 2026 20:56
6d67c0a to
a761e03
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
buildProjectsFromCache(session-cache.js) groups everysession_cacherow byprojectPath— subagent rows included. They are indexed from<folder>/<parent>/subagents/agent-*.jsonland carry the samefolderandprojectPathas their parent, withparentSessionIdset. So theproject.sessionsarray the renderer receives is a flat list of parents and children, and every consumer has to drop the children itself.processProjectSessionsdoes (allSessions.filter(s => !s.parentSessionId)); the DB side does too (getTotalCounts,WHERE parentSessionId IS NULL).The project header's Archive all sessions button did not:
stopSessionwas called on any subagent id that happened to be inactivePtyIds.The status bar's
N sessionstotal (renderDefaultStatus) had the same defect, and therefore disagreed with the stats panel's own total for the same data.Fix
Filter on
parentSessionIdin both places. Two one-line changes; no behavioural change for top-level sessions.Tests
test/dom-project-archive-all.test.js— 2 jsdom tests. Verified failing before the fix:The second test puts all four ids in
activePtyIds, so it also pins thestopSessionleak.Full suite: 673 tests, 666 pass, 0 fail, 7 pre-existing skips. ESLint: 0 errors.
renderDefaultStatusis not covered — there is no jsdom harness forapp.js. That one line is verified by reading only.Out of scope
The slug-group archive button has the same class of bug and is handled in #134.
One related defect is documented but not fixed here: when a search matches only subagent transcripts in a project,
refreshSidebarnarrowssessionsto those matches,processProjectSessionsfilters them all out, and the project drops out of the results entirely. Surfacing it needs a UI decision, not a filter. Written up in.ai/contexts/subagent-observability.md.Knock-on fixed in the same PR: the project vanished instead
Review caught a regression the two-line filter introduced. Once every top-level session is archived, the surviving subagent rows keep
project.sessionsnon-empty whilefiltered(top-level only) is empty — so the guard atsidebar.js:442returnednulland the render loopcontinued before reachingbuildSessionsListand its orphan-subagent bucket. Header and orphans both gone: the whole project disappeared from the default view although its data was still there.Not data loss — "Show Archived" brings it back. But the old behaviour hid this by accident: archiving the children too left
project.sessionsgenuinely empty, so the disappearance was correct. The filter alone turned a correct disappearance into an incorrect one, and systematically, from the first surviving subagent.The guard now keeps a project that still has indexed subagents and no active filter:
subagentIndexis already built two lines above and is the exact objectbuildSessionsListconsults for its orphan bucket — no second mechanism. Whenfilteredis empty,allTopLevelIdsis empty by construction, so every indexed subagent is an orphan:size > 0is the precise "there is something to show", not an approximation.!anyFilterActivecarries weight — without it, a starred/running/today filter or an active search would resurface every project owning a subagent, since a subagent satisfies none of those filters.Both halves are mutation-proven:
Guard cases verified unbroken: empty project, project whose top-level sessions are filtered out, empty project under an active filter,
_projectMatchedOnly, project with surviving top-level sessions.Full suite after rework: 685 tests, 678 pass, 0 fail, 7 pre-existing skips. ESLint: 0 errors.