You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Archiving a session should relocate it out of the startup scan path
#12931
"Archive session" currently only sets a marker: unarchiving removes the marker, the save location never changes, and the row is merely hidden from the list (there is a filter to view archived sessions). The session files stay in sessions/<workspace>/, so startup enumeration and eager projection still read them. Archiving cleans up the visible list but provides zero startup-time or memory relief.
sessions/: 10,502 files, ~1.26 GB (session.v4.jsonl.zstd, one per session) — venera 6,252 files/434 MB, bot-workspace 1,925 files/539 MB, consoles 908 files/109 MB, dsh 674 files/82 MB; largest single session log 38 MB compressed.
After a cold start the sidebar workspace tree takes very long to expand, and every unopened session shows an "unnamed" title (titles are generated lazily on open; most of these sessions are subagent-spawned with no user first message).
6 host OOM crashes in 2 days: exit 134, FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory, heap dying at ~2.4–2.9 GB after last-resort GC, 26 min–2 h after start. One stack shows the fatal allocation landing inside TurboFan v8::internal::compiler::CompilationDependencies while the heap is full — i.e. the bloated retained heap (dominated by session projection) leaves no headroom for background compilation.
When a session is archived, relocate its directory to an archive location that is excluded from the startup scan and from eager projection; move it back on unarchive. (Alternative, weaker: exclude archived session ids from eager projection and from cold enumeration, while keeping files in place.)
Acceptance Criteria
Archived sessions are not read during startup (no listing IO, no projection memory).
Unarchiving restores the session to its workspace with history intact.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Summary
"Archive session" currently only sets a marker: unarchiving removes the marker, the save location never changes, and the row is merely hidden from the list (there is a filter to view archived sessions). The session files stay in
sessions/<workspace>/, so startup enumeration and eager projection still read them. Archiving cleans up the visible list but provides zero startup-time or memory relief.Motivation
Real-world installation (dsh-desktop 0.2.2-rc.1, win32 x64, 64 GB RAM):
sessions/: 10,502 files, ~1.26 GB (session.v4.jsonl.zstd, one per session) — venera 6,252 files/434 MB, bot-workspace 1,925 files/539 MB, consoles 908 files/109 MB, dsh 674 files/82 MB; largest single session log 38 MB compressed.FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory, heap dying at ~2.4–2.9 GB after last-resort GC, 26 min–2 h after start. One stack shows the fatal allocation landing inside TurboFanv8::internal::compiler::CompilationDependencieswhile the heap is full — i.e. the bloated retained heap (dominated by session projection) leaves no headroom for background compilation.Proposed Solution
When a session is archived, relocate its directory to an archive location that is excluded from the startup scan and from eager projection; move it back on unarchive. (Alternative, weaker: exclude archived session ids from eager projection and from cold enumeration, while keeping files in place.)
Acceptance Criteria
All reactions