dsh-mini-remote 0.1.5 → 0.1.7

package/lib/tree.js

@@ -15,8 +15,6 @@
  * 它的会话（要读日志折标题，贵）。
  */
 import { basename } from 'node:path'
-import { statSync } from 'node:fs'
-import { findSessionLog } from './log-tail.js'
 
 /** 一个工作区默认最多列多少会话。手机上再多也划不动。 */
 export const SESSIONS_PER_WORKSPACE = 20
@@ -52,6 +50,180 @@ const CACHE_TTL_MS = 30_000
  */
 const caches = new WeakMap()
 
+/**
+ * 已经读出来的**会话标题**，也按 query 分开存一份。
+ *
+ * 为什么单独缓存它：清单本身（safeRecords）有 30 秒缓存，但冷会话的标题要去加载它的日志
+ * 才能折出来（DSH 的 readTitleSnapshots 就是逐个 load），实测展开一个工作区要 3 秒——
+ * 而这一步原先每次展开都重付一次。标题定下来基本不变，读过就该记住。
+ *
+ * 同样用 WeakMap 认"这份数据是谁的"，理由见上面 caches 的注释。
+ * **空标题也记**：会话确实没有标题时，没理由每次再去重读一遍；将来它有了标题，
+ * 事件流那条路（knownTitles）会先命中并覆盖掉。
+ */
+/**
+ * 展开工作区时，标题**最多**等这么久（毫秒）。
+ *
+ * 快的读取（几条会话、日志不大）在这个上限内就回来了，行为和原来一样；
+ * 慢的读取（实测有工作区要 19 秒）到点就放手，响应先走，标题留给后台补齐。
+ * 为什么是 250：这是"人感觉不到"和"人开始看表"之间的分界，也远小于手机页一次渲染的间隔。
+ */
+const TITLE_WAIT_MS = 250
+
+/**
+ * 内存里这份标题缓存放多久。
+ *
+ * 原来是 10 分钟，因为那时它是**唯一**的一份——过期就真的没了，得回去重读日志。
+ * 现在落盘那份（lib/title-cache.js）才是长期记忆，内存这份只是它的快照，
+ * 过期了从盘上再捞一次即可（见 titleCacheFor）。所以两边统一成同一个七天，
+ * 免得出现"盘上有、内存说没有、又去读一遍日志"这种白花的活。
+ */
+const TITLE_TTL_MS = 7 * 24 * 60 * 60 * 1000
+const TITLE_CACHE_MAX = 500
+const titleCaches = new WeakMap()
+
+/**
+ * 建内存缓存时**先把落盘那份灌进来**。
+ *
+ * 这一步就是"标题落盘"的全部意义所在：DSH 一重启，内存清零，而盘上那份还在，
+ * 于是展开一个读过的工作区依然是毫秒级——不必把 1.4 GB 日志重付一遍。
+ */
+function titleCacheFor(query, persisted) {
+  if (!query) return null
+  let entry = titleCaches.get(query)
+  if (!entry) {
+    entry = new Map()
+    for (const [id, row] of persisted?.all() ?? []) entry.set(id, row)
+    titleCaches.set(query, entry)
+  }
+  return entry
+}
+
+/**
+ * 记下一条标题。重插一次是为了让 Map 的顺序等于"最近更新在后"，好按容量淘汰最老的。
+ *
+ * 同时写进落盘那份（如果有）——**事件流里见到的新标题也走这条**，
+ * 于是盘上那个旧值当场就被覆盖，不会留着一个过时的说法。
+ */
+function rememberTitle(cache, id, title, persisted) {
+  if (!cache || !id) return
+  cache.delete(id)
+  cache.set(id, { title, at: Date.now() })
+  if (cache.size > TITLE_CACHE_MAX) {
+    const oldest = cache.keys().next().value
+    if (oldest !== undefined) cache.delete(oldest)
+  }
+  persisted?.set(id, title)
+}
+
+/**
+ * 后台读标题的**全局**并发上限。
+ *
+ * 一趟 readTitleSnapshots 就是"把这几份会话日志解压 + 折标题"，实测单条约 5 秒且吃 CPU。
+ * 列表不再干等之后，用户连续展开几个工作区就会有几趟同时在跑、互相抢。原先只有
+ * "按 query 去重"（见 titleInflight 的注释）——那只挡住同一个会话被读两遍，**不是闸门**：
+ * 五个工作区各读各的，照样是五趟并行。
+ *
+ * 为什么是 2：一台电脑上同时解两份日志，用户感觉不到卡；再多就会和别的事（模型请求、
+ * 手机页面自己）抢。而且这些标题本来就没人等着，晚几百毫秒没有任何代价。
+ */
+export const TITLE_CONCURRENCY = 2
+
+let titleRunning = 0
+const titleWaiting = []
+
+/** 排队等一个名额。fn 跑完（成了、抛了都算）把名额让给下一个。 */
+function withTitleSlot(fn) {
+  return new Promise((resolve, reject) => {
+    const run = () => {
+      titleRunning += 1
+      Promise.resolve()
+        .then(fn)
+        .then(
+          (value) => {
+            titleRunning -= 1
+            runNextTitle()
+            resolve(value)
+          },
+          (err) => {
+            titleRunning -= 1
+            runNextTitle()
+            reject(err)
+          },
+        )
+    }
+    if (titleRunning < TITLE_CONCURRENCY) run()
+    else titleWaiting.push(run)
+  })
+}
+
+function runNextTitle() {
+  const next = titleWaiting.shift()
+  if (next) next()
+}
+
+/**
+ * 取一条缓存标题。
+ *
+ * 「过期的当场删掉；"没查到过"和"查到是空标题"要分得出来」——后者返回的是空串，
+ * 前者返回 null，调用方（尤其是 pending 那个数）全靠这个区别。
+ *
+ * **内存里没有就去盘上找一眼**：内存这份上限 500 条，而本机 36 个工作区全展开一遍
+ * 就可能把它挤满；标题的长期记忆本来就在盘上（lib/title-cache.js），
+ * 被挤掉一条不该等于"回去重读 5 秒日志"。找到就顺手回灌进内存，只回灌不写盘——
+ * 盘上那份本来就是它。
+ */
+function cachedTitle(cache, id, persisted) {
+  const hit = cache?.get(id)
+  if (hit) {
+    if (Date.now() - hit.at <= TITLE_TTL_MS) return hit.title
+    cache.delete(id)
+  }
+  const fromDisk = persisted?.get(id)
+  if (typeof fromDisk !== 'string') return null
+  if (cache) rememberTitle(cache, id, fromDisk)
+  return fromDisk
+}
+
+/**
+ * query → 正在读日志的会话 id 集合。
+ *
+ * 不 await 之后有个新风险：用户连点两下、或两个标签页同时展开同一个工作区，
+ * 同一批冷会话会被读两遍。这里挡住重复的在途请求，读完即释放（失败也释放）。
+ */
+const titleInflight = new WeakMap()
+
+/**
+ * 后台把缺的标题读出来，写进缓存。**调用方不 await 它**。
+ *
+ * 为什么不 await：标题是列表里的装饰，没有它界面退回用日期（见 titleText 的注释），
+ * 而读它要加载会话日志——实测一个工作区里几条冷会话就是十几秒。那十几秒是用户在
+ * 盯着"正在读取…"干等，不该发生。
+ */
+async function fillTitles(query, cache, ids, persisted) {
+  if (!query?.readTitleSnapshots || !ids.length) return
+  let flying = titleInflight.get(query)
+  if (!flying) {
+    flying = new Set()
+    titleInflight.set(query, flying)
+  }
+  const todo = ids.filter((id) => !flying.has(id))
+  if (!todo.length) return
+  for (const id of todo) flying.add(id)
+  try {
+    // 读之前先过全局闸门（见 TITLE_CONCURRENCY）：这一步是这次改动里唯一真正吃 CPU 的地方。
+    const items = await withTitleSlot(() => query.readTitleSnapshots(todo))
+    for (const item of items ?? []) {
+      if (item?.status !== 'fulfilled') continue   // 读失败不进缓存，下次还会重试
+      rememberTitle(cache, item.sessionId, titleText(item.value?.title), persisted)
+    }
+  } catch (err) {
+    // 读不出来就没有标题，界面退回用日期，不影响切换。
+  } finally {
+    for (const id of todo) flying.delete(id)
+  }
+}
+
 async function safeRecords(query, { force = false } = {}) {
   if (!query) return []
   let entry = caches.get(query)
@@ -241,8 +413,14 @@ function shapeWorkspace(ws) {
  *
  * 标题分两步拿：插件自己在事件流里见过的（内存里就有，免费）优先；
  * 剩下的冷会话才去读日志。**只在展开一个工作区时才付这个代价**，所以有上限。
+ *
+ * `persisted` 是标题的落盘缓存（lib/title-cache.js）——读过一次的标题跨重启也算数。
+ * 它是可选的：没给就是纯内存的老行为，测试和 headless 组合都走这条路。
  */
-export async function listSessionsOf({ registry, query, agents, knownTitles, workspaceId, limit = SESSIONS_PER_WORKSPACE, force }) {
+export async function listSessionsOf({
+  registry, query, agents, knownTitles, persisted, workspaceId,
+  limit = SESSIONS_PER_WORKSPACE, force,
+}) {
   const ws = safeList(registry).find((w) => w.id === workspaceId)
   if (!ws) return null
 
@@ -254,21 +432,51 @@ export async function listSessionsOf({ registry, query, agents, knownTitles, wor
     .slice(0, limit)
 
   // 内存里已知的标题先用着，缺的再去读日志。
+  const cache = titleCacheFor(query, persisted)
   const titles = new Map()
   const missing = []
   for (const r of rows) {
-    const known = knownTitles?.get(r.header.id)
-    if (known) titles.set(r.header.id, known)
-    else missing.push(r.header.id)
+    const id = r.header.id
+    const known = knownTitles?.get(id)
+    if (known) {
+      titles.set(id, known)
+      rememberTitle(cache, id, known, persisted)
+      continue
+    }
+    const hit = cachedTitle(cache, id, persisted)
+    if (hit === null) missing.push(id)
+    else if (hit) titles.set(id, hit)
   }
+  // 标题只等一个很短的窗口：等得到就用上（和原来一样），等不到就放手、交给后台，
+  // 那几条先显示日期。缓存里已有的照旧直接用，所以反复展开同一个工作区始终是快的。
   if (missing.length && query?.readTitleSnapshots) {
-    try {
-      for (const item of await query.readTitleSnapshots(missing)) {
-        const title = item?.status === 'fulfilled' ? titleText(item.value?.title) : ''
-        if (title) titles.set(item.sessionId, title)
-      }
-    } catch (err) {
-      // 读不出来就没有标题，界面会退回用日期，不影响切换。
+    await Promise.race([
+      fillTitles(query, cache, missing, persisted),
+      new Promise((resolve) => setTimeout(resolve, TITLE_WAIT_MS)),
+    ])
+    for (const id of missing) {
+      const hit = cachedTitle(cache, id, persisted)
+      if (hit) titles.set(id, hit)
+    }
+  }
+
+  /**
+   * 「还有几条标题没读出来」——服务端把这件事**如实**告诉手机，手机据此决定要不要再问一次。
+   *
+   * 为什么要这个数：页面原来是"固定补三次"（1.5 秒 / 3 秒 / 3 秒），而一个工作区里
+   * 四五个冷会话实测要 19 秒才读完——三次补拉盖不住，标题还是长不出来，
+   * 用户只能退出去再进来。**猜次数不如问事实**：这个数归零，就是真的一条都不剩了。
+   *
+   * 两件事必须分开：
+   *   - "读过了、确实没有标题"（缓存里记的是空串）再等多久也不会有，不计入 pending；
+   *   - "还没读到"（cachedTitle 给 null）才算。
+   * 另外，拿不到 readTitleSnapshots 这个能力时一律 0：谁也不去读，却让页面一直问，那是骗人。
+   */
+  let pending = 0
+  if (typeof query?.readTitleSnapshots === 'function') {
+    for (const r of rows) {
+      const id = r.header.id
+      if (!titles.has(id) && cachedTitle(cache, id, persisted) === null) pending += 1
     }
   }
 
@@ -276,6 +484,7 @@ export async function listSessionsOf({ registry, query, agents, knownTitles, wor
     workspaceId,
     total: (ws.sessionIds ?? []).length,
     truncated: (ws.sessionIds ?? []).length > rows.length,
+    pending,
     sessions: rows.map((r) => {
       const id = r.header.id
       const status = agents?.get(id)?.status
@@ -289,39 +498,3 @@ export async function listSessionsOf({ registry, query, agents, knownTitles, wor
     }),
   }
 }
-
-/**
- * 会话日志的压缩体积（字节）。拿不到就返回 null——**不猜**。
- *
- * 为什么要它：`sessionQuery.readSession()` 会把整份事件解出来（还要做两次全量克隆），
- * 而且 0.1.7-rc.2 起 v3 日志要走 v3→v4 迁移，迁移过程会把这个父会话的
- * **每个直接子会话整份解码**。实测：26MB / 2.2 万事件的父会话带 310 个子会话时，
- * 默认约 4GB 堆 20 秒就 OOM（见 2026-09-25 事故）。所以读之前先量体积。
- */
-function logBytes(sessionId) {
-  const file = findSessionLog(sessionId)
-  if (!file) return null
-  try {
-    return statSync(file).size
-  } catch {
-    return null
-  }
-}
-
-/**
- * 一次「整份读」值不值得。子会话数用已缓存的 `listSessions()` 记录算（**无额外扫盘**）。
- *
- * 读不动有两类原因：① **子会话太多**（迁移要把它们全解出来）；② **自己太大**
- * （解 + 两次克隆 ≈ 体积的 5–8 倍）。两个信号都给出去，阈值由调用方定。
- *
- * @param {{query:object, sessionId:string}} args
- * @returns {Promise<{children:number, bytes:number|null}>} children = 以它为 parentSession 的会话数
- */
-export async function sessionScale({ query, sessionId }) {
-  const records = await safeRecords(query)
-  let children = 0
-  for (const r of records) {
-    if (r?.header?.parentSession === sessionId) children += 1
-  }
-  return { children, bytes: logBytes(sessionId) }
-}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-mini-remote",
-  "version": "0.1.5",
+  "version": "0.1.7",
   "description": "DSH 极简移动端遥控器：只把「你的指令」和「AI 的最终回复」送到手机，屏蔽全部中间过程。",
   "type": "module",
   "main": "lib/index.js",
@@ -23,7 +23,7 @@
     "test": "node --test \"test/*.test.mjs\""
   },
   "engines": {
-    "node": ">=22",
+    "node": "^22.19.0 || >=24.0.0",
     "dsh": ">=0.1.5-rc.2"
   },
   "author": "xingzhen199186",
@@ -37,7 +37,7 @@
   },
   "peerDependencies": {
     "@deepseek-ai/cordis": "^4.0.2",
-    "@deepseek-ai/dsh": ">=0.1.5-rc.2 <0.2.0",
+    "@deepseek-ai/dsh": ">=0.1.5-rc.2 <0.3.0",
     "@deepseek-ai/schemastery": "^3.18.3"
   },
   "peerDependenciesMeta": {