fix(sessions): guard syncFromHermes vs SessionDeleter race + import all sources on startup

[29206394]

Closes #352.

Summary

Two related bugs in the v0.5.3 session pipeline:

Bug 1 — SessionDeleter race condition (#352)

chat-run-socket.syncFromHermes asynchronously reads a Hermes session and writes its assistant/tool messages into the local mirror, then enqueues the Hermes session id into gc_pending_session_deletes. SessionDeleter drains that queue on a 5-minute timer, on profile switch, and immediately on start — with no coordination against in-flight reads. A drain that fires while a sync is mid-flight deletes the Hermes session out from under the reader, and assistant/tool messages never make it into the local DB.

Visible symptom: switching away and back to a session shows assistant replies vanishing; message_count decrements over time (6 → 5 → 4 …).

Fix: introduce an in-memory inFlightHermesSessionIds: Set<string> exported from session-deleter.ts. syncFromHermes adds the id BEFORE awaiting the read and removes it after the read completes — handling all three exit paths:

• Successful sync → enqueue delete, then release guard (ordering matters: the row must exist in the queue before drain can observe a guard-less candidate)
• Empty-detail early return → release guard, do not enqueue
• .catch() → release guard, do not enqueue (next successful sync will pick it up)

drain() filters out any candidate currently in the set, so periodic / profile-switch ticks defer deletion until the read is done.

Bug 2 — Startup sync silently drops CLI sessions

syncProfileSessions hardcoded 'api_server' as the source filter on listHermesSessionSummaries, so first-startup sync only imported chat sessions originated by the WebUI itself. CLI conversations (source='cli'), Telegram, Discord, Slack, etc. were never synced into the local DB and stayed invisible in the sidebar forever (sync only runs when the local DB is empty, so they couldn't be recovered without dropping the DB).

As a side effect, long CLI conversations that had been compressed into a parent_session_id chain weren't aggregated either, since they weren't synced at all.

Fix: pass undefined to listSessionSummaries so it returns roots from ALL sources. That function already filters out tool / compress_* sessions and aggregates parent_session_id chains, so no other change is needed.

Files changed

• packages/server/src/services/hermes/session-deleter.ts — export inFlightHermesSessionIds, filter eligible rows in drain()
• packages/server/src/services/hermes/chat-run-socket.ts — register/release guard around syncFromHermes
• packages/server/src/services/hermes/session-sync.ts — import all sources, not just api_server

3 files, +65 / −6 lines.

Test plan

• Local clean re-sync against a Hermes state.db containing mixed api_server + cli sessions across 4 profiles → imported 11 chains (previously 0 from this code path), correctly aggregating multi-step chains (max thread_session_count=5) into single sidebar entries.
• npm run build passes (vue-tsc + tsc + esbuild).
• Server starts cleanly, [session-sync] sync complete: synced=11, errors=0 in logs.
• Maintainer to verify: chat run → switch session → wait > 5 min → switch back → assistant messages should still be present.

Notes

• The guard is intentionally a process-local in-memory set rather than a DB column. Drain only runs in this process, and syncFromHermes only registers in this process, so a Set is sufficient and avoids schema migration.
• Ordering inside the success path (enqueue → then release) is load-bearing — reversing it reintroduces a small window where drain could miss the guard. This is documented in the code with a // IMPORTANT: comment referencing the issue.

[albert748]

Hey @29206394, thanks for the SessionDeleter fix — I've incorporated the inFlightHermesSessionIds guard into #373 along with the source filter fix and incremental sync (hermes_id dedup column). The incremental sync is the key piece: without it, the source filter fix alone doesn't help existing users who already have a populated DB (the count > 0 gate blocks re-sync forever). Hope we can consolidate — my PR has all three fixes in one commit. cc @54laowang