@threadbase-sh/streamer 1.44.2 → 1.44.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/index.js CHANGED
@@ -6096,6 +6096,7 @@ var ConversationCache = class _ConversationCache {
6096
6096
  this.onAgentFileDetected = options?.onAgentFileDetected;
6097
6097
  db.exec(SCHEMA);
6098
6098
  runSqliteMigrations(db, this.migrationsDir);
6099
+ const LIST_COLUMNS = "id, file_path, project_id, project_path, project_name, title, model, account, branch, message_count, last_activity, first_message, last_message, preview, source, provider";
6099
6100
  this.stmts = {
6100
6101
  getById: db.prepare("SELECT id FROM conversation_meta WHERE id = ?"),
6101
6102
  getFullById: db.prepare("SELECT * FROM conversation_meta WHERE id = ?"),
@@ -6176,17 +6177,17 @@ var ConversationCache = class _ConversationCache {
6176
6177
  WHERE conversation_tail.updated_at < excluded.updated_at
6177
6178
  `),
6178
6179
  list: db.prepare(
6179
- "SELECT * FROM conversation_meta ORDER BY last_activity DESC LIMIT ? OFFSET ?"
6180
+ `SELECT ${LIST_COLUMNS} FROM conversation_meta ORDER BY last_activity DESC LIMIT ? OFFSET ?`
6180
6181
  ),
6181
6182
  count: db.prepare("SELECT COUNT(*) as n FROM conversation_meta"),
6182
6183
  listByProject: db.prepare(
6183
- "SELECT * FROM conversation_meta WHERE project_path = ? ORDER BY last_activity DESC LIMIT ? OFFSET ?"
6184
+ `SELECT ${LIST_COLUMNS} FROM conversation_meta WHERE project_path = ? ORDER BY last_activity DESC LIMIT ? OFFSET ?`
6184
6185
  ),
6185
6186
  countByProject: db.prepare(
6186
6187
  "SELECT COUNT(*) as n FROM conversation_meta WHERE project_path = ?"
6187
6188
  ),
6188
6189
  listByProvider: db.prepare(
6189
- "SELECT * FROM conversation_meta WHERE provider = ? ORDER BY last_activity DESC LIMIT ? OFFSET ?"
6190
+ `SELECT ${LIST_COLUMNS} FROM conversation_meta WHERE provider = ? ORDER BY last_activity DESC LIMIT ? OFFSET ?`
6190
6191
  ),
6191
6192
  countByProvider: db.prepare("SELECT COUNT(*) as n FROM conversation_meta WHERE provider = ?"),
6192
6193
  deleteById: db.prepare("DELETE FROM conversation_meta WHERE id = ?"),
@@ -9773,7 +9774,12 @@ function managedToResponse(s, ptyAttached) {
9773
9774
  // the durable registry, so it is a previous run's session with no process
9774
9775
  // behind it — `resumable`, and `historical` rather than `managed`
9775
9776
  // (docs/plans/live-sessions-persistence-plan.md §4, Phase 1).
9776
- lifecycle: ptyAttached ? "attached" : s.rehydrated ? "resumable" : s.failureReason != null ? "failed" : "completed",
9777
+ // A session this run itself put on hold (grace timer, explicit hold_session,
9778
+ // idle reaper) is the other exception: the PTY is gone the same way an exit
9779
+ // leaves it gone, but the conversation is still resumable, not terminal —
9780
+ // `putOnHold` records that by leaving `statusSource: "shutdown"` (the only
9781
+ // place either runner sets it), so it is checked here alongside `rehydrated`.
9782
+ lifecycle: ptyAttached ? "attached" : s.rehydrated || s.statusSource === "shutdown" ? "resumable" : s.failureReason != null ? "failed" : "completed",
9777
9783
  lifecycleSource: ptyAttached ? s.reconciled ? "reconcile" : "spawn" : s.rehydrated ? "reconcile" : "exit",
9778
9784
  // We own its PTY, so `status` is the authoritative signal — no inferred
9779
9785
  // `activity` is attached for managed sessions.
@@ -10624,7 +10630,14 @@ var StreamerServer = class {
10624
10630
  // even though the registry has one — the name only appeared after a
10625
10631
  // restart rebuilt the row as a stub. Guarded so a runner that has not
10626
10632
  // derived one yet cannot blank a name set by enrichResumedSessionAsync.
10627
- ...session.sessionName != null && { sessionName: session.sessionName }
10633
+ ...session.sessionName != null && { sessionName: session.sessionName },
10634
+ // Without mirroring this, SessionStore's copy is frozen at whatever
10635
+ // `addManaged` saw at spawn ("spawn") forever, because updateManaged
10636
+ // is a partial merge — so managedToResponse can never tell a
10637
+ // grace-timer/idle-reaper hold (statusSource "shutdown") apart from a
10638
+ // genuine process exit ("process-exit"), and reports both as
10639
+ // `lifecycle: "completed"`. See managedToResponse in session-store.ts.
10640
+ ...session.statusSource != null && { statusSource: session.statusSource }
10628
10641
  });
10629
10642
  this.managedSessionsRepo?.recordStatus(
10630
10643
  session.id,