DSH Desktop 0.2.1-rc.1（macOS）主进程崩溃：Uncaught Exception: Error: setTypeOfService EINVAL

[Zwyverynb-del]

摘要

macOS 上 DSH Desktop 偶发弹出 Electron 原生错误框，随后应用退出：

A JavaScript error occurred in the main process
Uncaught Exception:
Error: setTypeOfService EINVAL

崩溃点在 Electron 主进程：主进程用 Node 全局 fetch（Node 内置 undici 7.29.1）代理渲染层发往 dsh-app://app/* 的请求；该内置 undici 在 writeH1 中对 socket.setTypeOfService() 没有 try/catch。macOS 在部分 socket 状态下让 setsockopt(IP_TOS) 返回 EINVAL，异常未被捕获，按 Electron 默认行为终止主进程。

QoS/IP_TOS 标记本身是可选优化，失败不影响请求收发；问题是这个可选失败被当成了致命异常。

环境

• DSH Desktop：0.2.1-rc.1（nightly）
• Electron：44.7.0
• Node：24.21.0（process.versions.undici = 7.29.1）
• DSH 自带 npm undici：8.11.2（其 client-h1 已带 guard）
• macOS：27.0.1 (26A434)，arm64

现象 / 崩溃栈

Uncaught Exception:
Error: setTypeOfService EINVAL
    at Socket.setTypeOfService (node:net:913:13)
    at writeH1 (node:internal/deps/undici/undici:8021:16)
    at Object.write (node:internal/deps/undici/undici:7758:18)
    at _resume (node:internal/deps/undici/undici:9691:54)
    at resume (node:internal/deps/undici/undici:9624:7)
    at Client.<computed> (node:internal/deps/undici/undici:9401:35)
    at node:internal/deps/undici/undici:9574:26
    at Socket.<anonymous> (node:internal/deps/undici/undici:3342:13)
    at Socket.wrapper (node:events:639:12)
    at Socket.emit (node:events:514:28)

根因

1. Node 24.21 内置 undici 7.29.1 在 writeH1 中无条件执行：

   if (socket.setTypeOfService) {
     socket.setTypeOfService(request.typeOfService)
   }

   request.typeOfService 默认 0，因此每个 HTTP/1.1 请求都会调用；该调用没有 try/catch。

2. macOS 上 Socket.setTypeOfService 在 node:net:913 抛出 ErrnoException（EINVAL），异常沿调用栈逃逸。

3. DSH 主进程 lib/main.js 的 forwardWebRequest（lib/main.js:8291）使用全局 fetch 代理页面请求，主进程没有 uncaughtException 处理器；异常落到 Electron 默认处理，弹出原生错误框并退出应用。

对照：DSH 依赖的 npm undici 8.11.2 在 lib/dispatcher/client-h1.js 中已把这一步做成 best-effort：

function setTypeOfService (socket, request) {
  if (typeof socket.setTypeOfService !== 'function') return
  const typeOfService = request.typeOfService
  if (typeOfService === undefined) return
  const currentTypeOfService = socket[kTypeOfService]
  if (currentTypeOfService === typeOfService) return
  try {
    socket.setTypeOfService(typeOfService)
    socket[kTypeOfService] = typeOfService
  } catch {
    // QoS marking is best-effort. setTypeOfService() can throw synchronously on
    // some platforms depending on socket state, but that must not abort the request.
  }
}

也就是说：npm undici 已经处理了这个问题，问题只出在 Node 内置的那份副本。

触发条件

EINVAL 与 socket 状态相关。公开报告中常见的状态包括：TLS over HTTP CONNECT、连接复用、半关闭/重连、VPN/代理环境。本地无法稳定复现，属于低频偶发。

补充判据：崩溃发生时 ~/Library/Logs/DeepSeek Harness/crash-*.log 没有对应 host 崩溃记录，符合“主进程崩溃、Electron 原生对话框不落盘”的特征。

建议修复（按推荐顺序）

方案 A：主进程启动时包一层 setTypeOfService（最小改动，覆盖所有调用点）

在第一次 fetch 之前执行（例如 lib/main.js 模块顶部）：

import net from 'node:net'

const TRANSIENT = new Set(['EINVAL', 'ENOPROTOOPT', 'ENOTSUP', 'EOPNOTSUPP', 'EBADF'])
const proto = net.Socket.prototype
const original = proto.setTypeOfService

if (typeof original === 'function' && !original.__dshTosGuard) {
  const guarded = function setTypeOfService(tos) {
    try {
      return original.call(this, tos)
    } catch (error) {
      const code = error && error.code
      const message = error && typeof error.message === 'string' ? error.message : ''
      if (TRANSIENT.has(code) || /\b(EINVAL|ENOPROTOOPT|ENOTSUP|EOPNOTSUPP|EBADF)\b/.test(message)) {
        return this
      }
      throw error
    }
  }
  guarded.__dshTosGuard = true
  proto.setTypeOfService = guarded
}

要点：

• 只吞“当前 socket 不支持/状态不允许”的 errno，其他错误继续抛，避免掩盖真实缺陷；
• 幂等，重复安装不会叠加 wrapper；
• 对 forwardWebRequest、authenticateWebHost 以及后续可能新增的 fetch 全部生效。

方案 B：让主进程改用自带 undici 8.11.2 的 fetch

forwardWebRequest 改用 import { fetch } from 'undici'（8.11.2 已带 guard）。注意主进程当前 dependencies 里没有 undici，需要显式加入依赖并确认 asar 内解析路径；这比方案 A 改动大。

方案 C：升级 Node 内置 undici

如果后续 Node 版本的内置副本已合入同样的 guard，升级 Electron/Node 即可。需要确认 Node 上游对应的修复版本。

方案 D（仅兜底，不建议单独使用）

主进程注册 process.on('uncaughtException')，仅针对 setTypeOfService + EINVAL 的形状做过滤，其余错误 rethrow。能挡住弹窗，但会掩盖同类真实错误，建议只作为方案 A 之外的额外防线。

验证建议

1. 在测试中把 net.Socket.prototype.setTypeOfService 替换为抛 EINVAL 的桩，驱动一次 fetch；
2. 断言请求仍正常返回、进程没有 uncaught 异常；
3. 同时验证非 transient 错误（例如 ERR_INVALID_ARG_TYPE）仍会抛出，防止 guard 过宽。

为什么不是插件问题

DSH 插件运行在 host（cordis profile）与渲染层，不会加载进 Electron 主进程；主进程只执行 asar 内的 lib/main.js，没有插件扩展点。因此无法通过 profile 插件规避此崩溃，供排查参考。

参考

• 同类修复（Electron 应用吞掉该错误）：open-design issue Idea + plugin: an enforced pain-point check to stop rabbit-holing #895 / PR ds你自己都不在源码上支持切换思维等级。本轮运行失败The `reasoning_content` in the thinking mode must be passed back to the API. INVALID_REQUEST #906
• 兜底实现参考：dsh-our-free-model PR 官方说明文档中的企微小助手无法添加联系人 #270
• Node 内置 undici 调用点：node:internal/deps/undici/undici 的 writeH1

[hugo2046]

补一份本机的实测，只补主帖和 #9557 里没有的两点；分析结论（方案 A–D）我完全同意，不重复。

1. 触发面可以确定性复现了

环境：DSH Desktop 0.2.1-rc.5、Electron 44.7.0、Node 24.21.0、process.versions.undici = 7.29.1（与主帖一致）。

socket 状态（客户端视角）	setTypeOfService()
已连接，两端都保持（IPv4 / IPv6 / unix domain）	OK
connect 尚未完成	THROW EBADF
只有客户端 end()	OK
只有服务端 FIN	OK
服务端 accept 即 FIN + 客户端也 end()	THROW EINVAL（3/3）
服务端 RST（destroy()）	OK
destroy() 之后 / TLS socket	OK（handle 已释放；TLSSocket._handle 无此方法，net.js:902 早返回）
取值 0 / 184 / 255	OK（256 抛 ERR_OUT_OF_RANGE，属另一类错误）

结论：不是取值问题，而是「双向 FIN 之后、handle 尚未释放」这个窗口——优雅关闭的竞态点。调用一旦落在该窗口内必炸；#9557 里「无法稳定复现」这一步可以补上了。

最小复现（零依赖，跑在 Electron 自带 node 上）：

const net = require('node:net')
const srv = net.createServer(s => { s.on('error', () => {}); s.end('bye') }) // accept 即 FIN
srv.listen(0, '127.0.0.1', async () => {
  const s = net.connect({ host: '127.0.0.1', port: srv.address().port, family: 4 })
  s.on('error', () => {})
  await new Promise(r => s.once('connect', r))
  await new Promise(r => setTimeout(r, 20))
  s.end()                                // 客户端也 FIN
  await new Promise(r => setTimeout(r, 30))
  try { s.setTypeOfService(0) }          // writeH1 里那次调用的同形调用
  catch (e) { console.log(e.message) }   // setTypeOfService EINVAL
  s.destroy(); srv.close()
})

2. 上游状态：方案 C（等内置副本修好）短期不成立

• nodejs/undici#6075（open）记录：修复 [BUG] session_projcache.json — 每次会话更新全量重写 74MB（写放大 / SSD 磨损） #5547 只合入 8.x，7.x 线未回移；Node 24.22.1 带的仍是 undici 7.30.1，未保护。
• 所以当前能真正落地的只有方案 A（收窄 transient errno 的 guard）和方案 B（改走 asar 内 8.11.2 的 fetch）。

3. 顺带一个暴露面实测

同一份 Electron 内，一个完全不加载 DSH 的脚本连发 3 次全局 fetch，每次都命中 writeH1 → setTypeOfService(0)（内置源 2952 行 typeOfService ?? 0，请求对象上总有值，因此这记 syscall 永远会下）。暴露面是所有走全局 fetch 的代码路径，不只渲染层代理那一条——这也能解释为什么不同用户在插件市场、普通会话等不同操作下都能撞到。