dsh-mobile-plugin 0.1.91 → 0.1.93

package/lib/mobile/stream.js

@@ -4,7 +4,13 @@
  * dsh-mobile 流式：SSE 转发目标会话的增量事件。
  *
  * 订阅宿主事件流，仅转发目标会话的 session/event 帧（增量事件），
- * 每 15s 发一行注释保持连接；客户端断开即取消订阅。
+ * 每 15s 发一行注释 + 一帧 `session/heartbeat` 数据帧；客户端断开即取消订阅。
+ *
+ * 为什么要那帧心跳：注释行只是保活，客户端一个事件都收不到。而「流被正常收尾」
+ * （中转重启、隧道掉了、宿主自己结束响应）在 App 那边看起来和「这条流还开着」一模一样
+ * —— react-native-sse 在 readyState 走到 DONE 时既不派发 error 也不派发 close。所以
+ * App 需要一个**自己数得到**的活口，两拍没到就主动断开重连（见 app 侧
+ * services/viewmodels/stream-liveness.ts）。这帧不带 seq、不进消息模型、不写缓存。
  *
  * 断线恢复：SSE 客户端重连时携带 `Last-Event-ID: <sessionId>:<seq>`（或查询参数
  * `lastSeq=<seq>`）。服务端先在 history 中回放 `seq > lastSeq` 的事件（收敛状态），
@@ -37,6 +43,14 @@ const questions = require('./questions.js');
 const SSE_FLUSH_PADDING_BYTES = 2048;
 const REPLAY_WINDOW = 3000; // 断线补偿回放的最大事件数
 
+/**
+ * keepalive 节奏，同时也是 `session/heartbeat` 的间隔。
+ *
+ * 必须与 App 的 `STREAM_HEARTBEAT_MS` 一致（`app/src/services/viewmodels/stream-liveness.ts`，
+ * 由 `test/stream-liveness.test.cjs` 的跨仓断言钉着）。
+ */
+const HEARTBEAT_MS = 15_000;
+
 /**
  * 可回答的审批请求帧类型。宿主 apiProxy 的 `requestedFrame()` 发的是 mux 帧
  * `approval/requested`（`rpcId` 在帧级、`approvalId` 在 payload）；会话事件
@@ -80,7 +94,8 @@ function writeSse(res, payload, frame) {
     // 审批帧没有 seq，按默认口径会在软水位上被丢掉（见上面那条策略）。但它是「人工决策
     // 的入口」不是草稿：丢一张，手机就再也看不到那张卡（软水位只在客户端跟不上时到，
     // 回放也不覆盖这一段）。它一次审批也就一两帧，不是撑爆写队列的那类帧。
-    shedWhenBuffered: (value) => !isApprovalPayload(value) && shedWithoutSeq(value),
+    // 心跳同理必须保住：丢了它，App 会把一条健康的流判成死链（见 isLivenessHeartbeat）。
+    shedWhenBuffered: (value) => !isApprovalPayload(value) && !isLivenessHeartbeat(value) && shedWithoutSeq(value),
   });
 }
 
@@ -94,6 +109,19 @@ function isApprovalPayload(payload) {
     || type === 'question/requested' || type === 'question/resolved';
 }
 
+/**
+ * 这一帧是「App 用来数活口」的心跳，不是聊天内容。
+ *
+ * 它走和正文一样的 writeSse（所以同样受背压闸门管），但**必须**在软水位上被保住：
+ * 心跳被丢掉就等于这条流没说话，App 会在 35s 后把一条完全健康的连接判死并重连 ——
+ * 那是比「丢一张草稿」贵得多的代价。它一帧一百多字节，不是撑爆写队列的那类帧。
+ *
+ * 它不带 seq，所以**绝不能**推进 `lastDeliveredSeq`（那会让回放跳过一个真事件）。
+ */
+function isLivenessHeartbeat(payload) {
+  return Boolean(payload) && payload.type === 'session/heartbeat';
+}
+
 /**
  * 解析断线续传位置：
  *  - `Last-Event-ID: <sessionId>:<seq>`（标准 SSE 头）；
@@ -152,8 +180,18 @@ async function handleStream(ctx, req, res) {
       clearInterval(keepAlive);
       ac.abort();
       try { res.end(); } catch { /* ignore */ }
+      return;
+    }
+    // 注释行客户端看不见，所以每一拍再补一帧数据心跳：App 靠「最近真的收到过帧」判断
+    // 这条流还在说话（见 app 侧 services/viewmodels/stream-liveness.ts）。写不出去同样
+    // 说明客户端已经不在，按上面那条路径收尾。
+    if (!writeSse(res, { type: 'session/heartbeat', sessionId, at: Date.now() }).ok) {
+      logStream(sessionId, 'heartbeat write failed', null);
+      clearInterval(keepAlive);
+      ac.abort();
+      try { res.end(); } catch { /* ignore */ }
     }
-  }, 15_000);
+  }, HEARTBEAT_MS);
   // 定时器不该拖住进程退出：宿主/worker 关停时若这条 SSE 还挂着，事件循环会被它按在
   // 15s 一拍上，收尾要等到下一次 tick 才发生（lib/sidecar-facade-worker.cjs 的
   // shutdown 就是这么做的）。测试里的 setInterval 桩没有 unref，所以先判类型。
@@ -214,7 +252,8 @@ async function handleStream(ctx, req, res) {
           const seq = p.event && Number.isFinite(p.event.seq) ? p.event.seq : null;
           // 回放已覆盖该 seq（回放与实时交界处）→ 跳过，避免重复交付。
           if (seq !== null && seq <= lastDeliveredSeq) continue;
-          const event = await resolveEventAttachments(ctx, sessionId, p.event);
+          // 引用模式：图片只下发 attachmentId，不取字节（见 attachments.js）。
+          const event = await resolveEventAttachments(ctx, sessionId, p.event, { referencesOnly: true });
           // 被 shed 的只可能是没有 seq 的增量（见 writeSse 的软水位闸）；它不推进水位，
           // 同一轮收尾的 assistant/message 会把完整正文补上。
           const result = await push(event, { ...frame, payload: { ...p, event } });
@@ -293,7 +332,7 @@ async function replaySince(ctx, sessionId, sinceSeq, res, signal, onDelivered) {
     for (const entry of candidates) {
       if (signal.aborted) break;
       const e = entry?.event || entry;
-      const event = await resolveEventAttachments(ctx, sessionId, e);
+      const event = await resolveEventAttachments(ctx, sessionId, e, { referencesOnly: true });
       // Keep replay data identical to live SSE data: the client reducer consumes
       // the event's own type (turn/start, assistant/message, etc.).
       const payload = { type: 'session/event', sessionId, event };

package/lib/mobile/uploads.js

@@ -9,13 +9,13 @@
  * 为什么分片，而不是一次 POST 传完：
  *   - 一次传完会把「能传多大的文件」变成一条运维配置 —— 中转的
  *     `MAX_BODY_BYTES`（dsh-mobile-server/lib/config.js）默认 50MB，插件自己的
- *     readJsonBody 默认只有 256KB。分片后单请求只有 1MB，与这些上限无关。
+ *     readJsonBody 默认只有 256KB。分片后单请求最大只有 2MB，与这些上限无关。
  *   - 手机侧网络不稳，分片能只重传坏掉的那一片，而不是整个文件。
  *
  * 为什么片内容走 base64 而不是原始字节：隧道协议本身支持原始字节
  * （lib/relay/protocol.js 的 httpBody 帧），但 App 侧没有任何「发二进制 body」的
  * 先例，RN 的 fetch 对 ArrayBuffer body 的支持也随版本变；图片通道本来就以 base64
- * 走 JSON，这里沿用同一条确定能用的路。代价是 33% 膨胀（单片 1MB → 约 1.37MB），
+ * 走 JSON，这里沿用同一条确定能用的路。代价是 33% 膨胀（单片 2MB → 约 2.73MB），
  * 仍远低于任何一层上限。
  *
  * 顺序与幂等：chunk 只接受「下一片」，重复送达同一片按重传处理（回当前 received，
@@ -32,11 +32,16 @@ const crypto = require('node:crypto');
 
 const { sendJson, readJsonBody } = require('../shared/http-util');
 
-// 片大小 256KB（base64 后约 341KB）：客户端一次请求的硬预算是 8s（`app/src/api/core.ts`
-// 的 REQUEST_TIMEOUT_MS），1MB 片在慢速上行网络上会撞超时；片越小越稳，代价只是多几次往返。
+// 片大小的**起步值** 256KB（base64 后约 341KB）：客户端一次请求的硬预算是 8s
+// （`app/src/api/core.ts` 的 REQUEST_TIMEOUT_MS），一上来就给大片的机器会在慢速上行
+// 网络上撞超时。客户端从这一档起步、按实测周期自己往上爬，爬到 `CHUNK_MAX_BYTES` 为止 ——
+// 局域网里能一路放大，公网上爬两下就停住。所以 begin 回的是「起步值 + 上限」两个数，
+// 不是「就传这么大」。
 const CHUNK_BYTES = 256 * 1024;
-/** 单片请求体上限：1MB base64 后约 1.37MB，留出信封与转义余量。 */
-const CHUNK_MAX_BODY = 4 * 1024 * 1024;
+// 片大小的上限（原始字节）：base64 后约 2.73MB，仍在下面 8MB 的请求体预算内。
+const CHUNK_MAX_BYTES = 2 * 1024 * 1024;
+/** 单片请求体上限：4MB base64 后约 5.33MB，留出信封与转义余量。 */
+const CHUNK_MAX_BODY = 8 * 1024 * 1024;
 /** 文件名上限（按字符算，避开各文件系统的字节上限差异）。 */
 const NAME_MAX_CHARS = 120;
 /** 暂存残片的最长寿命：手机上传中断后没人来 abort 的清理依据。 */
@@ -182,7 +187,8 @@ async function handleUploadBegin(_ctx, req, res) {
   };
   uploads.set(uploadId, job);
   scheduleUploadExpiry(uploadId, job);
-  sendJson(res, 200, { ok: true, uploadId, chunkSize: CHUNK_BYTES });
+  // chunkSize 是起步值、maxChunkSize 是天花板：客户端从前者开始按实测周期往上爬。
+  sendJson(res, 200, { ok: true, uploadId, chunkSize: CHUNK_BYTES, maxChunkSize: CHUNK_MAX_BYTES });
 }
 
 /** POST /api/mobile/v1/upload/chunk { uploadId, index, data } → { ok, received }。 */
@@ -259,4 +265,5 @@ module.exports = {
   inboxRoot,
   sweepExpiredUploads,
   CHUNK_BYTES,
+  CHUNK_MAX_BYTES,
 };

package/lib/mobile/workspaces.js

@@ -15,7 +15,8 @@
  */
 
 const { sendJson, readJsonBody } = require('../shared/http-util');
-const { stableRevision } = require('../shared/list-revision.js');
+const { isFreshRequest } = require('../shared/fresh-request');
+const { stableRevision, unchangedListBody } = require('../shared/list-revision.js');
 // 会话列表缓存归 sessions.js 管。归档/移动会话会改变列表行本身，必须让那边立刻失效，
 // 否则手机端按完「归档会话」，那一行最长 10 秒还留在侧栏里，看着像没归档。
 const { invalidateSessionList } = require('./sessions.js');
@@ -80,8 +81,21 @@ async function buildWorkspacesBody(ctx) {
   };
 }
 
-async function handleWorkspaces(ctx, _req, res) {
-  sendJson(res, 200, await buildWorkspacesBody(ctx));
+/**
+ * GET /api/mobile/v1/workspaces?rev=<上次的 revision>（token）
+ *
+ * 与 `/sessions` 同一条条件刷新契约（形状见 `lib/shared/list-revision.js` 的
+ * `unchangedListBody`）：`rev` 与最终 body 的 revision **恰好相等**时只回一句
+ * `{ok, unchanged:true, revision, generatedAt}`，不带 items。这条路由没有响应缓存，
+ * 所以只判「这份刚构建出来的 body」。
+ * `?fresh=1` 是写后刷新，必须拿到真数据，一律不走这条。
+ */
+async function handleWorkspaces(ctx, req, res) {
+  const url = new URL(req.url, 'http://x');
+  const rev = (url.searchParams.get('rev') || '').trim();
+  const body = await buildWorkspacesBody(ctx);
+  const unchanged = isFreshRequest(req.url) ? null : unchangedListBody(body, rev);
+  sendJson(res, 200, unchanged || body);
 }
 
 /**