@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.cjs CHANGED
@@ -6133,6 +6133,7 @@ var ConversationCache = class _ConversationCache {
6133
6133
  this.onAgentFileDetected = options?.onAgentFileDetected;
6134
6134
  db.exec(SCHEMA);
6135
6135
  runSqliteMigrations(db, this.migrationsDir);
6136
+ 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";
6136
6137
  this.stmts = {
6137
6138
  getById: db.prepare("SELECT id FROM conversation_meta WHERE id = ?"),
6138
6139
  getFullById: db.prepare("SELECT * FROM conversation_meta WHERE id = ?"),
@@ -6213,17 +6214,17 @@ var ConversationCache = class _ConversationCache {
6213
6214
  WHERE conversation_tail.updated_at < excluded.updated_at
6214
6215
  `),
6215
6216
  list: db.prepare(
6216
- "SELECT * FROM conversation_meta ORDER BY last_activity DESC LIMIT ? OFFSET ?"
6217
+ `SELECT ${LIST_COLUMNS} FROM conversation_meta ORDER BY last_activity DESC LIMIT ? OFFSET ?`
6217
6218
  ),
6218
6219
  count: db.prepare("SELECT COUNT(*) as n FROM conversation_meta"),
6219
6220
  listByProject: db.prepare(
6220
- "SELECT * FROM conversation_meta WHERE project_path = ? ORDER BY last_activity DESC LIMIT ? OFFSET ?"
6221
+ `SELECT ${LIST_COLUMNS} FROM conversation_meta WHERE project_path = ? ORDER BY last_activity DESC LIMIT ? OFFSET ?`
6221
6222
  ),
6222
6223
  countByProject: db.prepare(
6223
6224
  "SELECT COUNT(*) as n FROM conversation_meta WHERE project_path = ?"
6224
6225
  ),
6225
6226
  listByProvider: db.prepare(
6226
- "SELECT * FROM conversation_meta WHERE provider = ? ORDER BY last_activity DESC LIMIT ? OFFSET ?"
6227
+ `SELECT ${LIST_COLUMNS} FROM conversation_meta WHERE provider = ? ORDER BY last_activity DESC LIMIT ? OFFSET ?`
6227
6228
  ),
6228
6229
  countByProvider: db.prepare("SELECT COUNT(*) as n FROM conversation_meta WHERE provider = ?"),
6229
6230
  deleteById: db.prepare("DELETE FROM conversation_meta WHERE id = ?"),
@@ -9810,7 +9811,12 @@ function managedToResponse(s, ptyAttached) {
9810
9811
  // the durable registry, so it is a previous run's session with no process
9811
9812
  // behind it — `resumable`, and `historical` rather than `managed`
9812
9813
  // (docs/plans/live-sessions-persistence-plan.md §4, Phase 1).
9813
- lifecycle: ptyAttached ? "attached" : s.rehydrated ? "resumable" : s.failureReason != null ? "failed" : "completed",
9814
+ // A session this run itself put on hold (grace timer, explicit hold_session,
9815
+ // idle reaper) is the other exception: the PTY is gone the same way an exit
9816
+ // leaves it gone, but the conversation is still resumable, not terminal —
9817
+ // `putOnHold` records that by leaving `statusSource: "shutdown"` (the only
9818
+ // place either runner sets it), so it is checked here alongside `rehydrated`.
9819
+ lifecycle: ptyAttached ? "attached" : s.rehydrated || s.statusSource === "shutdown" ? "resumable" : s.failureReason != null ? "failed" : "completed",
9814
9820
  lifecycleSource: ptyAttached ? s.reconciled ? "reconcile" : "spawn" : s.rehydrated ? "reconcile" : "exit",
9815
9821
  // We own its PTY, so `status` is the authoritative signal — no inferred
9816
9822
  // `activity` is attached for managed sessions.
@@ -10661,7 +10667,14 @@ var StreamerServer = class {
10661
10667
  // even though the registry has one — the name only appeared after a
10662
10668
  // restart rebuilt the row as a stub. Guarded so a runner that has not
10663
10669
  // derived one yet cannot blank a name set by enrichResumedSessionAsync.
10664
- ...session.sessionName != null && { sessionName: session.sessionName }
10670
+ ...session.sessionName != null && { sessionName: session.sessionName },
10671
+ // Without mirroring this, SessionStore's copy is frozen at whatever
10672
+ // `addManaged` saw at spawn ("spawn") forever, because updateManaged
10673
+ // is a partial merge — so managedToResponse can never tell a
10674
+ // grace-timer/idle-reaper hold (statusSource "shutdown") apart from a
10675
+ // genuine process exit ("process-exit"), and reports both as
10676
+ // `lifecycle: "completed"`. See managedToResponse in session-store.ts.
10677
+ ...session.statusSource != null && { statusSource: session.statusSource }
10665
10678
  });
10666
10679
  this.managedSessionsRepo?.recordStatus(
10667
10680
  session.id,