[BUG] DSH Desktop 0.2.2-rc.3 启动崩溃分析报告

[phonknowunliv]

症状：Windows 客户端启动后弹出「DeepSeek Harness 无法使用」，无法进入界面。
崩溃记录：crash-*-main.log，source: main、phase: running、
[TypeError: fetch failed] { [cause]: Error: read ECONNRESET }。
结论：这不是 WAF / 网络问题，也不是 rc.3 引入的网络回归，而是 Desktop 主进程里一条
fire-and-forget 埋点请求的 1 秒 AbortSignal 掐断了 undici 共享连接池，紧接着的欢迎页初始化 RPC
复用了这条半死连接，得到 read ECONNRESET，进而被判为致命错误。
已在本机用真实 0.2.2-rc.3 安装包 100% 稳定复现，并验证了规避方案。

---

0. TL;DR（给维护者）

• 触发点：apps/desktop/src/main.ts:557 的 void track('desktop_app_launch', {})
  → welcome-backend.ts:140 用 AbortSignal.timeout(1000) 发 POST /api/productAnalytics/report。
• 该 RPC 在 Host 侧首次调用耗时 11.1 秒（collectEnvironment() + getDeviceIdentity() +
  OTLP 上报），必然超过 1 秒 → 客户端 abort。
• abort 破坏了到 127.0.0.1:<port> 的 keep-alive 连接；紧接着 main.ts:1457 → readWelcomeState()
  的 POST /api/settings/describe（同一 origin、同一 global dispatcher、无 deadline）复用它，
  9.0 秒后抛 read ECONNRESET。
• readWelcomeState() 是 reconcileBackend() 里被 await 的启动步骤（main.ts:680-695），异常进入
  main.ts:691 reportFatal(error, 'main')；此时 backend 已 ready，所以 phase: running（main.ts:151）。
• 与版本无关：rc.2 / rc.3 在这条链路（apps/desktop/src/**、apps/desktop-host/src/**、
  packages/util/http-proxy/src/**、packages/client/product-analytics/src/**）上字节级一致。
  这是竞态：只有"首次埋点上报 > 1 秒"才命中。
• 已在用户机器上以 profile 补丁（product-analytics.config.enabled = false）规避并通过
  真实运行时验证：report 11,083ms → 14ms，settings/describe ECONNRESET → 200。

---

1. 环境

项	值
应用	@deepseek-ai/dsh-desktop 0.2.2-rc.3（安装目录 D:\deepseek，扁平安装，2026-11-13 15:30）
安装包身份	dshBuildCommit = 6b729fedde0c8fd03af7afdf5a711aa64fe87c3b，dshBuildDirty = false，dshDesktopUpdateChannel = nightly
Electron / Node	44.7.0 / 24.21.0（与两版源码 pin 一致）
平台 / 语言	win32 x64 / zh-CN
DSH home	C:\Users\<user>\.dsh（profile 位于 .dsh\profiles\desktop）
崩溃记录	9 份 crash-*-main.log，没有任何 crash-*-host.log

安装包 resources/app.asar/package.json 里读到生产策略配置：
dshMandatoryUpdatePolicy.origin = https://harness.deepseek.com（authentication: anonymous）。
后文会说明：这条请求（社区 issue 里被 WAF 拦的那条）不是本次崩溃的原因。

---

2. 复现（可在任意装有 rc.3 的机器上执行）

复现脚本见附录 A。做法与 apps/desktop/src/host-process.ts 完全一致：

1. 用 ELECTRON_RUN_AS_NODE=1 + --expose-internals 启动
   <app.asar>/dsh/node_modules/@deepseek-ai/dsh-desktop-host/lib/index.js <runtimeDir> <profileDir> <primaryRuntime>，
   保留 IPC 通道；
2. 收到 ready 后，先 GET <url>（拿 303 + set-cookie，等价 authenticateWebHost）；
3. 按 shell 的真实顺序发 RPC，track() 那两条带 AbortSignal.timeout(1000)：
   productAnalytics/enabled → productAnalytics/report → settings/describe →
   llm/listConfigurableProviders → credentials/describe → account/getState。

2.1 实测结果

A. 只发欢迎页 RPC（跳过埋点）

RPC	结果
settings/describe	200, 52ms
llm/listConfigurableProviders	200, 6ms
credentials/describe	200, 10ms
account/getState	200, 5ms

→ Host 完全健康，stderr 为空，最后 exit 0。

B. 重放 shell 精确序列（含 1 秒 deadline）

步骤	结果
authenticateWebHost	303, 517ms
productAnalytics/enabled（1s deadline）	200, 48ms，返回 true
productAnalytics/report（1s deadline）	abort，1,013ms
settings/describe（无 deadline）	TypeError: fetch failed / read ECONNRESET，9,031ms

→ 与用户的两份 crash-*-main.log 完全一致；Host stderr 仍为空、exit 0。

C. 不给 deadline，测首次 report 的真实耗时

调用	结果
report #1	200, 11,083ms
report #2	200, 10ms
之后再用 1s deadline 发一次	200, 6ms（不再 abort）→ settings/describe 200

→ 决定是否命中崩溃的唯一变量，是首次 report 是否超过 1 秒。

D. 对照实验

变量	结果
DSH_TELEMETRY_DISABLED=1	report 仍 abort、settings/describe 仍 ECONNRESET（该变量不控制 product analytics）
profile 中 product-analytics.config.enabled: false	report 14ms，后续 4 条 RPC 全 200

---

3. 根因

3.1 崩溃链路

main.ts:557        void track('desktop_app_launch', {})              // 每次启动都发
main.ts:497-502    if (analyticsEnabled) await welcomeBackend?.report(event)   // 异常被吞
welcome-backend.ts:140
                   await invoke(..., AbortSignal.timeout(1000))      // 1 秒必然 abort
                   └─ Host: POST /api/productAnalytics/report
                      首次耗时 11.1s：
                        product-analytics/src/index.ts:103  collectEnvironment()（有界子进程查询）
                        product-analytics/src/index.ts:109  deepseekAccount.getDeviceIdentity()
                        product-analytics/src/index.ts:115  ctx.productTelemetry.emit()
                          → POST https://dsh-otel-collector.deepseeksvc.com/v1/logs
                            （host-product-telemetry-otel/src/index.ts:47 默认端点）
                   ⇒ abort 掉一条在途请求（共享 global dispatcher，同一 origin）
main.ts:1457       readWelcomeState()
welcome-backend.ts:58
                   await send('/api/settings/describe', { cookie })   // 无 deadline，复用连接池
                   ⇒ read ECONNRESET（实测 9.0s 后抛出）
main.ts:680-695    reconcileBackend() 的 catch
main.ts:691        reportFatal(error, 'main')
main.ts:151        phase = backendReady ? 'running' : 'startup'  ⇒ running

3.2 为什么是 phase: running 而不是 startup

• backendReady 只在 state.phase === 'ready' 时置真（main.ts:611-613）；
• ready 在 host.start()（含 authenticateWebHost）完成后才发布（backend-controller.ts:80-84）；
• 而 readWelcomeState() 在 reconcileBackend() 里位于 backend.start() 之后
  （main.ts:682-686）。
  ⇒ 失败点必定在 Host 就绪之后，phase 只能是 running。这也是"Host 没问题"的旁证。

3.3 为什么与 WAF 无关

• 断网仍复现：外网失败码会是 ENOTFOUND/EAI_AGAIN/ENETUNREACH，不可能是 ECONNRESET；
  报错指向 127.0.0.1:<port> 的 loopback 连接。
• 复现证明 Host 对全部 RPC 都返回 200（同一台机器、同一安装包）。
• 社区 issue 里被 WAF 拦的是另一条请求：
  GET https://harness.deepseek.com/api/v0/check_client_update?scenario=launch
  （apps/desktop/src/mandatory-update-policy.ts:161-167,193-196，main.ts:1589 触发，
  不带任何 User-Agent，只有 x-client-*）。它的异常在 check() 内部被完全捕获
  （mandatory-update-policy.ts:207），只会让"强制更新策略"不可用，不会弹崩溃框。
• WAF 的作用是间接的：它让 dsh-otel-collector.deepseeksvc.com / harness.deepseek.com
  这类链路变慢或失败，从而把首次 report 推到 1 秒以上，提高了命中概率。

3.4 为什么 rc.2 可能不崩

竞态，不是逻辑差异。两版在这条链路上字节级一致（见第 4 节）。是否命中取决于
"首次 report 是否 > 1 秒"，会随机器负载、网络、首次运行的缓存状态变化。

---

4. 版本对比结论（排除"rc.3 网络回归"）

对两个源码目录做全量 git diff --no-index + 全树 SHA-256 双向核对：

• 458 个文件修改、57 个新增、0 个删除；
• 其中 380 个是 package.json 只改版本号 0.2.2-rc.2 → 0.2.2-rc.3；
• pnpm-lock.yaml 变更 纯新增、0 删除 ⇒ 没有任何依赖解析变动
  （electron 44.7.0 / electron-updater 6.8.9 / ws 8.21.3 / zod 4.6.6 / undici 均未动）；
• 实质代码改动只有：新增可选包 packages/experimental/deepseek-chat-import/（默认不加载）、
  official-bundles 名单 +3 行、客户端 UI 插槽重构（ui-sidebar/ui-workspace/ui-primitives/
  ui-directory-picker-*）、session-log-export 导出健壮性；
• 整目录字节级一致：apps/desktop/src/**、apps/desktop-host/src/**、packages/boot/app-boot/src/**、
  packages/util/http-proxy/src/**、packages/client/product-analytics/src/**、
  packages/credentials/deepseek-account/src/**、packages/llm/llm/src/**、packages/telemetry/otel/src/**。

同时从安装包 app.asar 里确认：bundled @deepseek-ai/dsh 的依赖中包含
@deepseek-ai/dsh-deepseek-chat-import@0.2.2-rc.3 —— 即用户安装的 rc.3 与给出的 rc.3 源码一致，
不是"同号不同构建"。

---

5. 修复建议

P0（一行级，直接消除崩溃）

apps/desktop/src/welcome-backend.ts:136-140：不要用 1 秒 deadline 在共享连接池上发埋点请求。
两种都可行：

1. 给该请求独立的 dispatcher（按仓库策略使用 @deepseek-ai/dsh-http-proxy 的
   proxyRouteFor(url) / createRouteDispatcher，见 scripts/verify-no-bare-dispatcher.ts），
   让它的 abort 不可能污染欢迎页 RPC 的池；或
2. 把 AbortSignal.timeout(1000) 放宽/去掉，并把该请求改为启动后再发
   （main.ts:557 的 track('desktop_app_launch') 延后到 openInitialWindow() 之后）。

P1（提高启动韧性）

apps/desktop/src/main.ts:1457 / welcome-backend.ts:58：readWelcomeState() 对
TypeError: fetch failed（transport 类）做一次有界重试。单条被污染的连接不应该能杀死整个启动。

P2（Host 侧，消除 11 秒阻塞）

packages/client/product-analytics/src/index.ts:99-129：report() 不应在 RPC 调用栈里同步等待
collectEnvironment() + getDeviceIdentity()。建议"立即 ack、后台补齐环境字段"
（事件先入队，环境属性就绪后 enrich/emit），这样首次调用耗时与网络无关。

P3（降低默认风险）

• 桌面端 product analytics 目前没有用户可关的开关（product-analytics/src/index.ts:14-17
  注释明确 "no user settings surface"，enabled 是 volatile 配置）。建议：
  要么做成显式 opt-in，要么在首发版本默认关闭，直到 P2 完成。
• 同一模式在 welcome-backend.ts:136（analyticsEnabled，也是 1s deadline）存在，
  这次它 31–48ms 返回没触发，但属于同类隐患。

回归测试建议

在 Desktop 的宿主级测试里固定这个场景："一条被 abort 的 fire-and-forget RPC 之后，
随后的 settings/describe 必须成功"（可用本地 HTTP 服务器故意延迟第一条响应来驱动）。
现有 apps/desktop/tests/welcome-host.spec.ts / main-startup.spec.ts 可扩展。

另一个独立问题（顺带修）

apps/desktop/src/mandatory-update-policy.ts:161-167 的策略请求不发送 User-Agent，
只带 8 个 x-client-*；packages/credentials/deepseek-account/src/client-metadata.ts:37-46 的
账号/通知请求同样没有 UA。这类"零浏览器特征"的请求在华为云 WAF 规则下会被 429/重置。
虽然它不是本次崩溃的原因，但它是 issue 里被误判为根因的那条请求，建议按要求补上产品标识。

---

6. 本次本地修复流程（用户侧记录）

目标：不改动 app.asar（会触发 Electron 完整性校验），只通过共享 profile 的补丁层关闭埋点。

6.1 事实取证

1. 通过桌面快捷方式定位安装目录：D:\deepseek（DeepSeek Harness.exe FileVersion 0.2.2-rc.3）。
2. 解析 resources/app.asar 头部（Python 脚本，只读），读出 package.json /
   dsh/desktop-runtime.json / bundled @deepseek-ai/dsh 清单，确认：
   • 策略 origin = https://harness.deepseek.com；
   • dshBuildCommit = 6b729fed...、dshBuildDirty = false、channel nightly；
   • 安装包与 rc.3 源码一致（含 dsh-deepseek-chat-import@0.2.2-rc.3）。
3. 检查日志目录：9 份 crash-*-main.log，无 crash-*-host.log（fatal-recovery.ts:70
   只记录第一条致命错误，Host 侧诊断可能被吞，不能据此判断 Host 存活）。
4. 检查共享 profile %USERPROFILE%\.dsh\profiles\desktop：第三方插件已在 22:50/22:56 被
   "禁用第三方插件并重启"移除，但 23:25/23:26/23:27 仍崩 ⇒ 排除插件。

6.2 复现与定位

5. 复制 ~/.dsh 的 profiles/desktop 与 storages 到工作区副本（不动真实数据）；
6. 按 host-process.ts 的方式启动 Host（Electron Node 模式 + IPC），执行 repro/host-run.mjs：
   四条欢迎页 RPC 全 200 ⇒ Host 健康；
7. 执行 repro/host-run2.mjs（重放 shell 精确序列）：1.013s abort → 9.031s ECONNRESET ⇒ 复现；
8. 执行 repro/host-run3.mjs（放开 deadline）：首次 report 11,083ms，第二次 10ms ⇒ 定位到耗时来源。

6.3 修复

9. 在 profile 副本的 cordis.patch.yml 追加，验证有效（report 15ms，全部 200）：

- id: product-analytics
  name: "@deepseek-ai/dsh-client-product-analytics"
  config:
    enabled: false

10. 备份真实 profile 并写入（UTF-8 无 BOM、AppendAllText 方式，避免中途 BOM 破坏 YAML）：

$patch  = "$env:USERPROFILE\.dsh\profiles\desktop\cordis.patch.yml"
$backup = "$patch.bak-analytics-fix-$(Get-Date -Format yyyyMMdd-HHmmss)"
Copy-Item $patch $backup
# 追加：
#   - id: product-analytics
#     name: "@deepseek-ai/dsh-client-product-analytics"
#     config:
#       enabled: false

11. 用真实 profile 的副本再跑一次完整启动序列：report 14ms，
    settings/describe / llm/listConfigurableProviders / credentials/describe /
    account/getState 全部 200，Host stderr 为空。

6.4 生效与还原

• 生效：完全退出所有 DSH 桌面进程后重新启动 rc.3（profile 在启动时读取）。
• 还原：

Copy-Item "$env:USERPROFILE\.dsh\profiles\desktop\cordis.patch.yml.bak-analytics-fix-20261114-234006" `
          "$env:USERPROFILE\.dsh\profiles\desktop\cordis.patch.yml" -Force

6.5 影响与限制

• 只关闭"匿名产品分析"埋点，不影响任何功能；profile 与 rc.2 共享，因此 rc.2 也会一并关闭。
• 这是规避而非修复：根因仍在 shell 的 1 秒 abort + 共享连接池（P0）。官方修复后可删除该补丁。
• 若补丁后仍崩，说明命中点是另一个慢请求（同类模式还有 analyticsEnabled）；
  此时请提供新的 crash-*-main.log 与 repro/host-run2.mjs 的输出。

---

附录 A：复现脚本（工作区 repro/）

脚本	作用
host-run.mjs	启动 Host + IPC，只发 4 条欢迎页 RPC（Host 健康对照）
host-run2.mjs	重放 shell 精确序列（含 1s deadline），复现 ECONNRESET
host-run3.mjs	放开 deadline，测首次 report 的真实耗时（11.1s）

每个脚本顶部有 4 个常量需按目标机器调整：exe（安装目录主程序）、resources
（<install>\resources）、reproHome（用作 DSH_HOME 的临时目录，建议用 profile 的副本以保护真实数据）、
projectDir（<reproHome>\profiles\desktop）。

关键实现要点（与 host-process.ts 一致）：

spawn(exe, ['--expose-internals', entry, runtimeDir, projectDir, primaryRuntime], {
  cwd: projectDir,
  env: { ...process.env, ELECTRON_RUN_AS_NODE: '1', DSH_HOME, DSH_CLIENT_VERSION, DSH_PRIMARY_RUNTIME },
  stdio: ['ignore', 'pipe', 'pipe', 'ipc'],
})

RPC 形状与 welcome-backend.ts:52-70 一致：

POST /api/<ns>/<method>
content-type: application/json
cookie: <303 响应里的 set-cookie 第一段>

{"type":"client-request","rpcId":"<uuid>","method":"settings/describe","payload":{"args":{}}}

附录 B：关键文件与行号索引

文件	行	作用
apps/desktop/src/main.ts	497-502	track()：埋点上报，异常被吞
apps/desktop/src/main.ts	557	启动即 void track('desktop_app_launch')
apps/desktop/src/main.ts	680-695	reconcileBackend()（含 openInitialWindow）
apps/desktop/src/main.ts	691	reportFatal(error, 'main')
apps/desktop/src/main.ts	1455-1471	openInitialWindow()；1457 readWelcomeState()
apps/desktop/src/main.ts	151 / 611-613	phase / backendReady
apps/desktop/src/welcome-backend.ts	136 / 140	analyticsEnabled() / report() 的 1s deadline
apps/desktop/src/welcome-backend.ts	49, 58	send = fetch，invoke() 无 deadline
apps/desktop/src/backend-controller.ts	80-84	Host ready 之后才发布 ready
apps/desktop/src/host-process.ts	210-227 / 262-265	Host 启动方式 / 非零退出与 stderr
apps/desktop/src/fatal-recovery.ts	70	只记录第一条致命错误
packages/client/product-analytics/src/index.ts	14-17 / 99-129	无可配置开关 / report() 首次 11s 的实现
packages/host/product-telemetry-otel/src/index.ts	47	OTLP 默认端点
apps/desktop/src/mandatory-update-policy.ts	152, 161-167, 193-196, 207	无 UA 的策略请求（独立问题）
packages/bundle/web-app/cordis.patch.yml	49-54	product-analytics 的 enabled: true 来源