[Bug] macOS 桌面内更新失败："desktop update: task inspection timed out"（10s 硬超时 / 无日志 / inspect 与 lock 不可区分）

[JiangSiY]

摘要

macOS 上从 0.2.1-rc.3 应用内更新到 0.2.1-rc.5（nightly channel），点「安装并重启」后弹出「更新失败」，技术详情只有一行：

desktop update: task inspection timed out

整个过程没有任何日志可查。从 0.2.1-rc.5 的 app.asar 可以确认，这个错误来自 shell 对 Host 的 update-tasks 控制请求撞上 10 s 硬超时（lib/main.js:3859），而 Host 侧的 lock 需要把所有已准入的 /api 请求排空完才返回（dsh-desktop-host/lib/index.js:140-146）——流式响应在整段输出期间都不会结束，10 s 在结构上就可能永远等不到。inspect 与 lock 共用同一句文案，事后无法判断卡在哪一步。

English summary: On macOS, an in-app nightly update from 0.2.1-rc.3 to rc.5 failed with desktop update: task inspection timed out. Both the read-only inspect and the admission lock are sent over a single 10 s control deadline (lib/main.js:3857-3864), while the Host's lock awaits Promise.all(pendingRequests) over admitted /api requests (dsh-desktop-host/lib/index.js:140-146) — a streaming response keeps the drain open for its whole lifetime, so 10 s is structurally unreachable whenever a turn is still generating (or a response never finishes). Nothing is journaled: the update journal only exists when DSH_DESKTOP_UPDATE_JOURNAL_DIR is set (lib/main.js:12045-12046), and both inspect and lock failures surface with the same opaque message.

环境

OS	macOS 27.2 (26B123), Apple M1 Pro (arm64)
App	@deepseek-ai/dsh-desktop 0.2.1-rc.3 → 0.2.1-rc.5 (nightly)
Electron	44.7.0
Host	Node 24.21.0（随包 runtime）
更新路径	应用内更新，点击「安装并重启」

现象与时间线（2026-11-02）

• 10:34 更新包下载完成：~/Library/Caches/@deepseek-aidsh-desktop-updater/pending/deepseek-harness-0.2.1-rc.5-mac-arm64.zip（347,767,892 B），其 sha512 与 update-info.json 记录完全一致（包是完整的，不是下载问题）。
• 随后点「安装并重启」→ 弹「更新失败」，详情即上面那行。
• 失败时 Host 进程已连续运行约 6 天（10-27 08:50:50 由上一次 ShipIt 安装完成后启动）。
• 10:57:40 再次触发安装，ShipIt 开始安装，10:57:45 完成并重启到 rc.5。即：约 23 分钟后重试成功（期间是否重启过应用无法确认），说明不是永久性损坏或权限问题。

日志侧的缺口：

• ~/Library/Logs/DeepSeek Harness/ 只有 crash-*.log（最近一条 10-22），没有更新日志。
• ~/Library/Caches/com.deepseek.dsh.ShipIt/ShipIt_stderr.log 里 10:57 之前没有任何 11-02 记录 —— 与代码一致：失败发生在 beforeRestart() 阶段，还没走到 quitAndInstall()。

代码定位（0.2.1-rc.5，asar 内路径）

1. shell 侧的 10 s 硬超时 —— lib/main.js:3857-3864

/**
 * Inspect active work or lock request admission for update handoff.
 * @param action - Read-only inspection, admission lock, or recovery unlock.
 * @returns Whether live tasks would be affected. Locking drains admitted API requests before inspecting tasks;
 * an unanswered drain fails at the control-request deadline without authorizing installation.
 */
async updateTasks(action) {
    const response = await this.control({
        type: "update-tasks",
        action
    }, 1e4, "desktop update: task inspection timed out");
    ...
}

inspect、lock、unlock 全部走这一条路径，deadline 一律 1e4，错误文案也一律相同。

2. 安装序列 —— lib/main.js:12330-12376

const active = await host.updateTasks("inspect");        // 弹确认框之前
// ... 原生确认框 ...
try {
    const stillActive = await host.updateTasks("lock");  // 排空已准入请求
    ...
    await backend.stop();
    updateStoppedHost = true;
    ...
} catch (error) {
    if (!updateStoppedHost) await host.updateTasks("unlock").catch(console.error);
    throw error;
}

3. Host 侧 lock 的排空 —— dsh-desktop-host/lib/index.js:108-149

ctx.on("connection/request", async (_request, response, next) => {
    if (locked) { response.writeHead(503); response.end(); return; }
    const finished = Promise.withResolvers();
    pendingRequests.add(finished.promise);
    try { await next(); }
    finally { pendingRequests.delete(finished.promise); finished.resolve(); }
});
...
if (action === "lock") {
    locked = true;
    const generation = ++lockGeneration;
    await Promise.all(pendingRequests);   // 自身没有 deadline
    if (stopped) throw new Error("desktop update: Host is stopping");
    if (generation !== lockGeneration) throw new Error("desktop update: admission lock was superseded");
}
return hasDesktopActiveTasks(agents.list(), jobs);

next() 会等到响应结束才 resolve，所以流式响应在整个输出期间都留在 pendingRequests 里。只要有一条正在生成的长响应（或一条客户端断开后未收尾的响应），Promise.all 就不可能在这 10 s 内完成 —— 这是设计上"不取消已准入请求"与"10 s 硬超时"直接冲突的地方。

4. 可观测性缺口

• journal 只在设置了 DSH_DESKTOP_UPDATE_JOURNAL_DIR 时才创建（lib/main.js:12045-12046），生产环境默认没有 → 失败无任何记录。
• 失败只进入内存里的 error 状态；unlock 失败时仅 console.error（lib/main.js:12369-12371）。
• 失败对话框标题「更新失败」，正文是通用文案 updateInstallFailed，技术详情只有原始 message，没有"重试 / 退出重开 / 手动安装"的指引，也不显示仍在排空的请求数。

影响

用户看到的是一个没有信息量的失败弹窗，很容易误判为"更新包坏了、要重新下载"（本机上包是完好的）。在有长生成时重试会重复失败，用户可能一直装不上；而 autoInstallOnAppQuit = false（lib/main.js:7807）又让"退出应用自动安装"这条最自然的退路失效，所以连"重启一下"的直觉也不成立。

建议

1. 区分 action：inspect 与 lock 使用不同文案（例如 task inspection timed out / admission drain timed out），或在错误里带上 action、Host pid/uptime、pendingRequests.size、最老请求已等待时长。
2. 给 drain 独立的 deadline（与 shell 的 10 s 分离，例如 30–60 s 并上报进度），超时后把"仍在排空的请求数"报给用户，让用户能选择"稍等再试"还是"退出重开"。
3. journal 默认开启并写入 ~/Library/Logs/DeepSeek Harness/update.log：每次 state 变化、两个 control 请求各自耗时、Host pid/uptime。
4. 失败 UI 给出可操作路径：一个明确的「重试安装」入口（install() 本身可重入，lib/main.js:12597 已经有这个调用路径），以及"仍未成功时退出应用重开、或用更新缓存手动安装"。
5. 可选：既然用户在确认框里已经明确选择「停止任务并更新」，允许在 drain 超时后取消已准入的流式响应。
6. 至少在失败提示里说明 autoInstallOnAppQuit = false 的含义，避免用户以为"退出就会装"。

证据

• 缓存包的 sha512 与 update-info.json 一致；解压后 codesign --verify --deep --strict 通过，spctl 判定 accepted, source=Notarized Developer ID，版本为 0.2.1-rc.5。
• ShipIt 日志 10:57:40 → 10:57:47 记录了一次完整的"移走旧 bundle → 放入新 bundle → 启动"（即重试成功）。
• 失败时刻 Host 已运行 6 天（pid 与 uptime 如上），且失败发生在 ShipIt 开始之前。

如果愿意，我可以帮忙验证加日志 / 加 deadline 之后的 nightly 版本（这台机器可以随时复现并在相同 workspace 下测试）。