[macOS] Uncaught main-process exception: setTypeOfService EINVAL (internal undici unguarded)

[Edelweiss-Snow]

==================================================================
[macOS] 主进程未捕获异常 setTypeOfService EINVAL
Uncaught main-process exception: setTypeOfService EINVAL
（内置 undici 裸调用 + Node 仅在 Windows 做了容错）
(internal undici calls it unguarded; Node only swallows the error on Windows)

【环境 / Environment】
中：App 为 DeepSeek Harness 桌面版 0.2.0-rc.2（nightly，2026-09-29 构建，
已是更新源当前最新版）；系统 macOS（Apple Silicon）；系统代理已关闭，
无 VPN、无网络扩展；重启 Mac 后问题依旧。
EN: DeepSeek Harness desktop 0.2.0-rc.2 (nightly, built 2026-09-29, latest on
the update feed); macOS on Apple Silicon; system proxy disabled, no VPN and
no network extension installed. The error persists even after a full reboot.

【现象 / Symptom】
中：使用中偶发弹窗 "A JavaScript error occurred in the main process"，
非致命，点 OK 后可继续使用，但反复出现。
EN: A dialog "A JavaScript error occurred in the main process" pops up
intermittently during normal use. It is non-fatal — the app keeps working
after clicking OK — but it recurs constantly.

【错误栈 / Stack trace（原文）】
Uncaught Exception:
Error: setTypeOfService EINVAL
at Socket.setTypeOfService (node:net:684:13)
at writeH1 (node:internal/deps/undici/undici:8022:16)
at Object.write (node:internal/deps/undici/undici:7758:18)
at _resume (node:internal/deps/undici/undici:9656:54)
at resume (node:internal/deps/undici/undici:9589:7)
at Client. (node:internal/deps/undici/undici:9370:35)
at node:internal/deps/undici/undici:9539:26
at Socket. (node:internal/deps/undici/undici:3342:13)

【定位 / Root cause（已逐项核对安装包内文件 / verified against the installed bundle）】

中：1) 崩溃走的是 Node 运行时内置的 node:internal/deps/undici（运行时二进制
Contents/Resources/runtime/primary-runtime/dependencies/node/bin/node 实际版本
为 v24.21.0）。该内置 undici 写请求时是裸调用，没有任何保护：
EN: 1) The crash goes through the undici bundled INSIDE the Node runtime
(node:internal/deps/undici; the bundled binary reports v24.21.0). That
internal undici calls the API unguarded when writing a request:

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

中：2) Node 的 net.Socket.setTypeOfService 原生实现只对 Windows 做了
best-effort 容错，macOS 上直接抛出：
EN: 2) Node's net.Socket.setTypeOfService implementation treats the call as
best-effort on Windows only, and rethrows on macOS:

   const err = this._handle.setTypeOfService(tos);
   // ... we ... do not throw on Windows.
   if (err && !isWindows) {
     throw new ErrnoException(err, 'setTypeOfService');
   }

中： 当 socket 处于瞬时状态（睡眠唤醒、网络切换、连接复用等）时，内核对
IP_TOS 返回 EINVAL，异常无人捕获，一路冒泡到主进程弹出对话框。
EN: When the socket is in a transient state (after sleep/wake, a network
switch, connection reuse, etc.), the kernel returns EINVAL for IP_TOS; the
exception is uncaught and bubbles all the way up to the main process, which
shows the dialog.

中：3) 关键反差：app.asar 内打包的较新 undici 已经修复了这个问题——
setTypeOfService 助手外面包了 try/catch，注释写明 "QoS marking is
best-effort. setTypeOfService() can throw synchronously on some platforms
depending on socket state, but that must not abort the request."
但主进程内置 fetch 走的仍是上面那份旧的内置 undici，没有用上修复。
EN: 3) Key contrast: the NEWER undici bundled in app.asar already fixes this —
its setTypeOfService helper is wrapped in try/catch with the comment
"QoS marking is best-effort ... must not abort the request". But the
main-process built-in fetch still uses the older internal undici, so the fix
is never reached on this path.

【复现 / Reproduction】
中：在普通 IPv4、IPv6、IPv4-mapped socket 上设置 ToS 0~255 全部正常，无法稳定
复现；只在特定 socket 状态下偶发，与新版 undici 注释中 "throws synchronously
on some platforms depending on socket state" 的描述一致。
EN: Setting ToS 0–255 works fine on ordinary IPv4, IPv6, and IPv4-mapped sockets,
so it cannot be reproduced deterministically; it only fires under specific
socket states, consistent with the note "throws synchronously on some
platforms depending on socket state".

【建议修复 / Suggested fix】
中：三选一即可：
a. 升级内置 Electron/Node 到包含 undici best-effort 修复的版本；
b. 让主进程 HTTP 请求统一走 app.asar 中已带 try/catch 的那份 undici；
c. 在 Node 的 setTypeOfService 中对 macOS 也应用与 Windows 相同的
best-effort 容错（EINVAL 时不抛出）。
EN: Any of the following would fix it:
a. Upgrade the bundled Electron/Node to a version whose internal undici
includes the best-effort fix;
b. Route main-process HTTP requests through the undici already shipped in
app.asar (which has the try/catch);
c. Apply the same best-effort handling to macOS as Windows in
Socket.setTypeOfService (do not throw on EINVAL).

【影响 / Impact】
中：非致命但高频干扰，且用户无法通过关闭代理、重启、清理网络接口规避；
ToS 仅为 QoS 标记，忽略其错误对请求功能无影响。
EN: Non-fatal but high-frequency and unavoidable via proxy settings, reboot, or
network-interface cleanup. ToS is only a QoS hint, so ignoring its error has
no functional impact on the request.

[arielli001]

Confirmed root cause, plus a one-line fix on the DSH side.

Verified on macOS 26 (Tahoe), DSH 0.2.1-rc.2 (Electron 44.7.0 → Node 24.21.0, undici 7.29.1). Everything below was read directly out of the running binary (process.binding('natives')) and out of app.asar — not guessed from version numbers.

1. Why the exception escapes

node:internal/deps/undici/undici (7.29.1), writeH1, line 8020:

if (socket.setTypeOfService) {
  socket.setTypeOfService(request.typeOfService);   // no try/catch
}

net.js (Node 24.21.0), lines 891–918:

if (tos !== this[kSetTOS]) {
  this[kSetTOS] = tos;                              // set *before* the syscall
  const err = this._handle.setTypeOfService(tos);
  if (err && !isWindows) {
    throw new ErrnoException(err, 'setTypeOfService');   // :913
  }
}

src/tcp_wrap.cc (v24.21.0) — TCPWrap::SetTypeOfService returns UV_EINVAL when uv_tcp_getsockname() reports a family that is neither AF_INET nor AF_INET6:

} else {
  // Unsupported socket family (e.g. AF_UNIX)
  args.GetReturnValue().Set(UV_EINVAL);
  return;
}

(It picks IP_TOS for AF_INET and IPV6_TCLASS for AF_INET6. On macOS the mismatch cases are also EINVAL: IP_TOS on an AF_INET6 socket and IPV6_TCLASS on an AF_INET socket both fail — measured directly via setsockopt.)

Upstream undici already guards this (nodejs/undici#5547), but it landed in Node 26. There is no backport to the Node 24 line, which is what Electron 44 ships.

2. Reachability inside DSH: only two call sites, both in the main process

lib/main.js in 0.2.1-rc.2 contains exactly two bare fetch( calls (i.e. Node's undici) and one net.fetch:

line	code	stack
8230	authenticateWebHost(url) → await fetch(url, { redirect: "manual" })	vulnerable
8291	dsh-app:// protocol handler → await fetch(target, init)	vulnerable
12194	connectDesktopWelcome(ready.url, (i, init) => net.fetch(i, init), …)	immune (Chromium stack)

Line 12194 already does the right thing, so this looks like an oversight on authenticateWebHost rather than a deliberate choice.

Reachability per launch is const ready = await host.start(); hostCookie = await authenticateWebHost(ready.url); — exactly one roll of the dice per start, which matches the reported symptom (rare, and almost always at startup).

3. Full stack (from the modal dialog)

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:9639:4)
    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:9342:13)
    at Socket._wrapJSImpl (node:events:639:12)
    at Socket.emit (node:events:514:28)

Note undici:9574 is client.emit('connect', …); client[kResume](); — the write happens on the first flush of a freshly connected socket.

4. It is worse than a log line: it is modal

There is no uncaughtException / unhandledRejection handler anywhere in lib/main.js (grep returns zero matches), so Electron's default dialog.showErrorBox runs. That dialog is modal and blocks the main process, so the window sits at "Loading plugins…" and then freezes behind it. Users reasonably report this as "the app won't open" — many never realise they have to dismiss the box first. That, not the exception itself, is the real severity here.

5. Suggested fix

Cheapest first:

1. Use Electron's net.fetch instead of the global fetch in authenticateWebHost (8230) and in the dsh-app:// handler (8291). net.fetch goes through Chromium's network stack and never touches net.Socket.prototype.setTypeOfService, so the bug becomes unreachable without changing the bundled Electron/Node. Line 12194 already demonstrates the pattern.
2. Bump Electron to a build on Node ≥ 26 / an undici with [BUG] session_projcache.json — 每次会话更新全量重写 74MB（写放大 / SSD 磨损） #5547.
3. Stopgap: install a main-process uncaughtException handler early (before host.start()) so this can never block the UI.

6. Already ruled out (so this doesn't get re-investigated)

• Not the proxy. HTTPS_PROXY/HTTP_PROXY are never exported in the user's shell (the if nc -z 127.0.0.1 7897 guard fails), system proxy is off, and DSH has no proxy setting.
• Not IPv6. harness.deepseek.com has no AAAA record. Connections to ::1 and to v4-mapped addresses set IPV6_TCLASS and succeed.
• Not a plugin. Reproduced with dsh-better-sidebar disabled. More broadly, HTTPS and unix-socket traffic cannot reach this path at all: a TLSSocket's _handle is a TLSWrap and a unix socket's is a Pipe, neither has setTypeOfService, so net.js:902 returns before the syscall. Only plain http:// is exposed.
• Downgrading does not help. 0.1.7-rc.1 ships Electron 44.0.0 / Node 24.18.1, which is affected too.

Happy to run any instrumented build if it helps pin down which socket ends up in the UV_EINVAL branch.

[Scared11a]

补一个 2.0.21-next 仍然复现的数据点，并补充一个之前没记录过的次生故障：崩溃之后应用无法靠重启自愈。

环境与现场

• DSH NEXT 2.0.21-next（dsh 0.2.1-rc.4）、Electron 44.7.0、Node 24.21.0、macOS 27.0.1 (26A434) arm64
• 2026-10-31 18:32:57 / 18:33:01 / 18:33:07（+08:00），连续三次启动都在同一处崩溃：

Error: setTypeOfService EINVAL
    at Socket.setTypeOfService (node:net:913:13)
    at writeH1 (node:internal/deps/undici/undici:8021:16)
    ...

• 和 [macOS] Uncaught main-process exception: setTypeOfService EINVAL (internal undici unguarded) #9557 的 0.2.0-rc.2 不同，这一版是致命的：日志里紧跟着 run.forced-exit，主进程直接退出，不是“点掉弹窗还能继续用”。

新增：崩溃后的 60 秒启动死锁

第一次崩溃后旧 host 子进程没有退出（shutdown.request 之后没有 host.process exit），下一次启动被标记为 run.previous-unclean，随后每次启动都卡在：

[desktop] host.start.failed ... "Host startup exceeded 60 seconds"

• 18:34:38 失败一次（60 010 ms），18:37:41 再失败一次（60 003 ms）
• 直到 18:38:35 旧进程/旧状态消失，同一份安装 736 ms 就启动完成

也就是说，用户遇到这个崩溃之后，反复重开应用是没用的，反而会不断 spawn 出起不来的 host；只能等残留进程被清掉，或者手动强制退出再试。这比单次崩溃本身的伤害更大。

与已有定位的关系

根因与 #9557 的结论一致，不需要重新排查：主进程 forwardWebRequest 用全局 fetch 转发 dsh-app://app/* 到本地 http://127.0.0.1:<port>，走 Node 内置 undici 7.29.1 的裸调用；npm undici 的 guard 覆盖不到这条路径。本次环境里系统代理是开着的（Clash 127.0.0.1:7897），实例已连续运行约 24 小时，但按 #9557 的排除项，代理/IPv6 都不是必要条件，这里只是说明环境。

建议（在 #9557 的三条之外补一条恢复逻辑）

1. 主进程尽早安装窄范围的 uncaughtException 处理，或把 forwardWebRequest 换到已带 guard 的 undici；
2. 强制退出/异常退出时先回收旧 host（SIGTERM → 短超时 SIGKILL），再启动新 host；把 60 秒盲等改成“检测到残留实例 → 提供强制重启”，而不是每次干等 60 秒；
3. 失败时记录目标 host/端口和 socket 状态（现在完全不知道是哪条连接触发的）。

诊断材料

这次的三组诊断都在：崩溃弹窗截图、desktop-next.log（449–454 行三次崩溃；465 行 previous-unclean；470–473、484 两次 60 s 失败）、两份 host-boot failure report、环境信息。需要的话我可以把整包贴上来，或按你们要求的方式提供。

另外 #11309 是同一崩溃在 0.2.1-rc.1 上的报告，可以一起看。