@adhdev/daemon-core 0.9.82-rc.438 → 0.9.82-rc.439

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.
@@ -263,35 +263,50 @@ function executeSqlite(src: NativeHistorySqliteSource, input: NativeHistoryInput
263
263
  catch { return null; }
264
264
 
265
265
  try {
266
- let sessionRow: any;
267
- try {
268
- // session_query may reference `?` to receive the session's
269
- // start-time floor in seconds (e.g. WHERE started_at >= ?).
270
- // That gives spec authors a robust way to keep prior-session
271
- // rows out of a fresh dashboard view without inventing their
272
- // own time arithmetic in SQL. When the caller didn't pass a
273
- // session floor (i.e. no live session is associated with the
274
- // call), we use 0 so spec queries that bind `?` still produce
275
- // a sane result rather than choking the whole executor.
276
- const sessionFloorSeconds = typeof input.sessionStartedAtMs === 'number'
277
- ? Math.floor(input.sessionStartedAtMs / 1000)
278
- : 0;
279
- const stmt = db.prepare(src.session_query);
266
+ const requested = input.providerSessionId || '';
267
+ let sessionId: string;
268
+ if (requested) {
269
+ // Session pin: the caller already bound this instance to a
270
+ // specific provider session, so read THAT session directly and
271
+ // skip the newest-wins `session_query` entirely. hermes ≥0.14
272
+ // spawns a fresh `sessions` row per internal sub-session, so the
273
+ // `ORDER BY started_at DESC LIMIT 1` pick drifts to a different
274
+ // id on every read. Left unpinned that churns the bound session
275
+ // (each re-bind re-hydrates unbounded history daemon
276
+ // saturation) and reads completion evidence from the wrong
277
+ // session (turn never finalizes). Binding straight to the
278
+ // requested id fixes both. Existence is validated below by the
279
+ // spec's own `message_query` returning rows for this id, so we
280
+ // don't hardcode any schema here.
281
+ sessionId = requested;
282
+ } else {
283
+ let sessionRow: any;
280
284
  try {
281
- sessionRow = stmt.get(sessionFloorSeconds);
282
- } catch {
283
- sessionRow = stmt.get();
284
- }
285
- } catch { return null; }
286
- if (!sessionRow) return null;
287
- // First column of the first row is the session id.
288
- const sessionIdRaw = Object.values(sessionRow)[0];
289
- const sessionId = sessionIdRaw == null ? '' : String(sessionIdRaw);
285
+ // session_query may reference `?` to receive the session's
286
+ // start-time floor in seconds (e.g. WHERE started_at >= ?).
287
+ // That gives spec authors a robust way to keep prior-session
288
+ // rows out of a fresh dashboard view without inventing their
289
+ // own time arithmetic in SQL. When the caller didn't pass a
290
+ // session floor (i.e. no live session is associated with the
291
+ // call), we use 0 so spec queries that bind `?` still produce
292
+ // a sane result rather than choking the whole executor.
293
+ const sessionFloorSeconds = typeof input.sessionStartedAtMs === 'number'
294
+ ? Math.floor(input.sessionStartedAtMs / 1000)
295
+ : 0;
296
+ const stmt = db.prepare(src.session_query);
297
+ try {
298
+ sessionRow = stmt.get(sessionFloorSeconds);
299
+ } catch {
300
+ sessionRow = stmt.get();
301
+ }
302
+ } catch { return null; }
303
+ if (!sessionRow) return null;
304
+ // First column of the first row is the session id.
305
+ const sessionIdRaw = Object.values(sessionRow)[0];
306
+ sessionId = sessionIdRaw == null ? '' : String(sessionIdRaw);
307
+ }
290
308
  if (!sessionId) return null;
291
309
 
292
- const requested = input.providerSessionId || '';
293
- if (requested && sessionId !== requested) return null;
294
-
295
310
  const messageRows: any[] = db.prepare(src.message_query).all(sessionId);
296
311
  if (!messageRows || messageRows.length === 0) return null;
297
312