[desktop 0.1.7-rc.2] dsh-app:// 转发的响应无法流式返回：/plugins/events(SSE) 恒报 net::ERR_FAILED，连带会话状态、权限预设目录、审批提示与插件热更新一起失效

[suiyideali]

[desktop 0.1.7-rc.2] dsh-app:// 转发的响应无法流式返回：/plugins/events(SSE) 恒报 net::ERR_FAILED，连带会话状态、权限预设目录、审批提示与插件热更新一起失效

环境

• macOS 27.0（26A428），Apple Silicon
• DeepSeek Harness 桌面端 0.1.7-rc.2（内置 @deepseek-ai/dsh-desktop-runtime 0.1.7-rc.2）
• profile：desktop（默认 profile）
• 该 profile 另装有 3 个第三方插件（dsh-selection-toolbar、dsh-approval-gate、@tt-a1i/archify-dsh），但请注意：失败的是内置 host 路由（/plugins/events），转发层出错的证据与任何插件代码无关；插件 bundle 走同一转发路径且工作正常（这也正是"有限响应能过、流式响应过不去"这条不对称的对照）。

现象

桌面窗口 DevTools（F12）Console 持续报同一个错误，且自动重试也一直失败（单次会话中出现 3 次以上）：

Failed to load resource: net::ERR_FAILED
dsh-app://app/plugins/events:1

关键对照：同一路径直连 HTTP 完全正常

用桌面窗口自身的认证 cookie 直接请求同一个路由（curl，非浏览器）：

$ curl -D - -H "Cookie: dsh-auth-<authority-derived>" -H "Accept: text/event-stream" \
       http://127.0.0.1:19387/plugins/events
HTTP/1.1 200 OK
content-type: text/event-stream
cache-control: no-cache
connection: keep-alive
Transfer-Encoding: chunked

: connected

data: {"type":"graph","graph":{"rev":"40d2a2b32253","entries":[{"id":"@deepseek-ai/dsh-client-ui-open-in-app","url":"plugins/??...&rev=f44f7506b4ea","rev":"f44f7506b4ea","inject":[...]},...]}}

• 6 秒内稳定收到 28,710 字节，SSE 帧格式正确；
• Node 侧 fetch + response.body.getReader() 也能正常拿到 chunk（首 chunk 13B / : connected，随后 28,710B 的 graph 事件）；
• 只有经过 dsh-app:// 协议转发这一层才失败。

已排除的原因

1. 自定义协议特权没问题（app.asar 中已正确注册）：

   protocol.registerSchemesAsPrivileged([{ scheme: SCHEME, privileges: {
     standard: true, secure: true, supportFetchAPI: true,
     corsEnabled: true, stream: true, codeCache: true
   }}]);

2. host 侧路由健康：200 + 合法 text/event-stream + 合法首帧。
3. URL 处理无误：手工模拟 forwardWebRequest 的 target.pathname = source.pathname; target.search = source.search，转发后 URL 与被请求 URL 逐字节相同（?? 虽被 URL 解析器归入 search，但序列化后完全一致）。
4. 响应头 withhold 是正确的：content-encoding 被去掉是必要且正确的——host 对插件 bundle 会 gzip（实测 Content-Encoding: gzip + Vary: Accept-Encoding），而主进程的 Node fetch 已经解压，原样透传反而会错。实测 10 MB 的插件 bundle 走同一转发路径完全正常。

根因假设

forwardWebRequest（main process）使用全局 fetch（Node/undici），并把它的 response.body 直接交给自定义协议的 new Response(...)：

async function forwardWebRequest(request, host, cookie) {
  /* ... */
  const response = await fetch(target, init);          // ← Node/undici 的 fetch
  const outgoing = new Headers(response.headers);
  for (const name of WITHHELD_RESPONSE_HEADERS) outgoing.delete(name);
  if (PLUGIN_BUNDLE_PATH.test(source.pathname)) outgoing.set("cache-control", "no-store");
  return new Response(response.body, { status: response.status, headers: outgoing });
}

有限长度的响应能通过（Electron 可以读完整个 body 再交付——所以 10 MB 的插件 bundle 正常）；无限流式的响应过不去（永远不会"读完"），表现为 net::ERR_FAILED。/plugins/events 恰好就是那条永不结束的 SSE。

波及面（这是影响最严重的部分）

/plugins/events 是客户端获取「host → client 事件/状态」的唯一通道（其首帧即 {"type":"graph",...}，携带模块图 rev 与模块清单）。它一死，以下四件事同时失效，均在本机稳定复现：

1. 会话状态恒为空：客户端内 sessions.current 一直是空值，第三方插件拿不到当前会话 id（只能自行兜底，例如退回 composer 会话）。符合事件通道未送达的状态。
2. 权限预设目录到不了客户端：本机按某个插件（社区 approval-gate）的官方说明在 ~/.dsh/profiles/desktop/cordis.patch.yml 里手工添加了 permission 预设（含 auto-approve，name: 自动审批（Flash）），host 侧应已生效，但会话权限下拉里始终不出现该选项；而 label 在 shipped 客户端 locale 字典里的 Auto review 不受影响。这与 @deepseek-ai/dsh-permission-presets README 中「进程级 catalog() Remote 返回完整可选快照，注册/移除 Auto 会发出 permission-presets/catalog-changed 通知，客户端先订阅再重新读取目录」的描述相符——该通路依赖这条事件通道。
3. 审批提示弹不出来、工具调用直接卡住：把会话审批策略设为 ask 后，需要审批的工具调用会一直等待且不出现任何提示。审批请求需要客户端 UI 应答，事件推不到客户端时即表现为挂起。
4. 装/卸插件后插件会"消失"，且用户没有应用内刷新入口：bundle URL 形如

   dsh-app://app/plugins/??<modules>&rev=<per-process revision>
   

   实测 rev 重建后旧 URL 立即 404（rev=32092783b4f0 → 404；当前 rev → 200）。客户端因收不到 graph 事件而继续持用旧 URL，模块加载失败，第三方插件静默失效，必须整页刷新或重启应用才恢复。而打包版把「刷新页面」菜单项隐藏了：

   const development = !app.isPackaged;                  // 打包版 = false
   ...development ? [ { label: reloadPageMenu, role: "reload" }, ... ] : []

   同时 devToolsItems 的 toggleDevTools 也是 visible: false（只留了 F12）。因此普通用户既没有"刷新页面"，也看不到"开发者工具"，只能 ⌘Q 重启。

建议修法（任选其一即可）

1. forwardWebRequest 改用 Electron 的 net.fetch（Chromium 网络栈），而不是全局 fetch，让流式 body 与自定义协议的 Response 兼容；
2. 或让 /plugins/events 这类流式路由不走协议转发，像 DESKTOP_IPC.boot 返回的 streamBaseUrl 那样，由客户端直连 host origin（http://127.0.0.1:<port>，cookie 注入机制已具备）。

附：用户侧临时绕过

在浏览器里打开 host 的 HTTP 源（同一 profile），此时 /plugins/events 是同源直连、不经过 dsh-app:// 转发层，事件通道恢复正常：

1. 取桌面窗口正在使用的认证 cookie（名由 Host 派生、值由本次 activation 密钥签发）：

   sqlite3 ~/Library/Application\ Support/@deepseek-ai/dsh-desktop/Cookies \
     "select name||'='||value from cookies where name like 'dsh-auth%' order by last_update_utc desc limit 1;"

2. 浏览器打开 http://127.0.0.1:19387/，用 DevTools → Application → Cookies 写入该 name/value，刷新即可。

[suiyideali]

补充：官方文档依据 + 一个可 A/B 判真伪的最小复现

（接 #7868 正文。以下把根因假设从"推测"推进到"可被维护者几分钟内确认或推翻"。）

1. 官方文档里，protocol.handle 内做转发的标准写法是 net.fetch，不是全局 fetch

Electron net 模块文档（docs/api/net.md）原文：

The net module is a client-side API for issuing HTTP(S) requests. It is similar to the HTTP and HTTPS modules of Node.js but uses Chromium's native networking library instead of the Node.js implementation …

net.fetch(input[, init]) — Sends a request, similarly to how fetch() works in the renderer, using Chromium's network stack. This differs from Node's fetch(), which uses Node.js's HTTP stack.

而文档给出的"在 protocol.handle 里转发"的示例，用的正是 net.fetch 转交原请求：

protocol.handle('https', (req) => {
  if (req.url === 'https://my-app.com') {
    return new Response('<body>my app</body>')
  } else {
    return net.fetch(req, { bypassCustomProtocolHandlers: true })
  }
})

本仓库的实现与此不同：forwardWebRequest 使用的是全局 fetch（主进程里即 Node.js 的 HTTP 栈），随后手工重建 Response 并把 response.body 交给自定义协议：

const response = await fetch(target, init);                       // Node/undici
return new Response(response.body, { status: response.status, headers: outgoing });

这与观察到的不对称一致：有限长度的响应可以读完再交付（所以 10 MB 的插件 bundle 走同一路径完全正常），永不结束的响应读不完 → net::ERR_FAILED；而 /plugins/events 恰好是唯一的无限 SSE。

2. 既有前例：protocol.handle + 流式处理是已知易错区

electron/electron#41872 — [Bug]: ReadableStream is malformed when protocol.handle'd：标签 component/protocol / bug / status/confirmed / has-repro-gist，由 #41894 修复（2024-04）。

需要如实说明：该 issue 讲的是请求体流（renderer → handler，duplex: "half"），与本例的响应体流并非同一条代码路径，因此不应作为直接证据。本机桌面端为 Electron 44.0.0（Electron Framework.framework 的 CFBundleVersion），远晚于该修复，故其请求体缺陷在此不会复现。列在这里有两点理由：

• forwardWebRequest 的 init 同样传了 request.body + duplex: "half"，对带 body 的转发请求会踩到同一类问题；
• 说明"自定义协议 + 流"在该项目里属历史易错区，值得采用官方推荐的 net.fetch（Chromium 栈）。

3. 最小复现（不含任何第三方插件，约 20 行）

// repro.cjs
//   USE_NET_FETCH=0 npx electron repro.cjs   → 预期 FAIL（复现本问题）
//   USE_NET_FETCH=1 npx electron repro.cjs   → 预期 OK （验证修法方向）
const { app, protocol, net, BrowserWindow } = require('electron')
const http = require('http')

// 一个永不结束的 SSE，等价于 /plugins/events
const server = http.createServer((req, res) => {
  res.writeHead(200, { 'content-type': 'text/event-stream', 'cache-control': 'no-cache' })
  res.write(': connected\n\n')
  const timer = setInterval(() => res.write('data: tick\n\n'), 1000)
  req.on('close', () => clearInterval(timer))
})

protocol.registerSchemesAsPrivileged([{ scheme: 'probe', privileges: {
  standard: true, secure: true, supportFetchAPI: true,
  corsEnabled: true, stream: true, codeCache: true
} }])

app.whenReady().then(async () => {
  await new Promise((r) => server.listen(0, '127.0.0.1', r))
  const target = `http://127.0.0.1:${server.address().port}/events`
  const useNet = process.env.USE_NET_FETCH === '1'

  protocol.handle('probe', async () => {
    const response = await (useNet ? net.fetch(target) : fetch(target))   // ← 唯一差别
    const headers = new Headers(response.headers)
    for (const name of ['set-cookie', 'content-encoding', 'content-length',
      'transfer-encoding', 'connection', 'keep-alive', 'te', 'trailer',
      'upgrade', 'proxy-authenticate', 'proxy-authorization']) headers.delete(name)
    return new Response(response.body, { status: response.status, headers })
  })

  const win = new BrowserWindow({ show: false })
  await win.loadURL('about:blank')
  const out = await win.webContents.executeJavaScript(`
    (async () => {
      try {
        const res = await fetch('probe://app/events')
        const reader = res.body.getReader()
        const first = await Promise.race([
          reader.read(),
          new Promise((_, rej) => setTimeout(() => rej(new Error('timeout: no first chunk in 3s')), 3000))
        ])
        return 'OK: first chunk ' + first.value.byteLength + 'B'
      } catch (e) { return 'FAIL: ' + e.message }
    })()
  `)
  console.log((useNet ? 'net.fetch    → ' : 'global fetch → ') + out)
  app.quit()
})

判据说明（请如实对待）：

• 这是判据，不是已经跑过的结论——报告方无法在本机隔离运行一个 Electron 应用，无法给出该 A/B 的实测输出。
• 若 global fetch 失败而 net.fetch 成功 → 本假设（Node 栈的流与自定义协议不兼容）成立，修法 1 即可；
• 若两者都失败 → 问题在 protocol.handle 的响应流本身，与本假设无关，请直接采用修法 2。

4. 修法（对应官方已有机制）

1. 按官方示例改用 net.fetch，并优先采用文档里"转交原请求"的形态 net.fetch(req, { bypassCustomProtocolHandlers: true })——它顺带省掉了手工重建请求头（含 cookie 注入、origin/host 删除、sec-fetch-site 删除等）那整段逻辑；
2. 或让 /plugins/events 这类流式路由不经过协议转发，由客户端直连 host origin（照 DESKTOP_IPC.boot 返回的 streamBaseUrl 的既有做法，cookie 注入机制已具备）。

5. 为什么不只是"一个插件的问题"

即便本条讨论的是桌面端转发层，它的影响面是用户可见的四类故障（详见正文）：会话状态恒空、权限预设目录到不了客户端、审批提示不出来导致工具调用挂起、以及装/卸插件后第三方插件静默失效且用户没有应用内刷新入口（打包版隐藏了「刷新页面」菜单项，DevTools 也只留 F12）。因此这条通道值得优先修。

[PerryLink]

你的根因假设在代码里成立——转发层用的就是全局 fetch，而且流被重新包了一层

1. 关键那一行

桌面壳的协议处理在 apps/desktop/src/main.ts:617-632：dsh-app://app/... 里不属于前端静态资源的路径，统一走

return forwardWebRequest(request, hostUrl, hostCookie)      // main.ts:629

而 apps/desktop/src/web-document.ts:77-93 就是转发实现，核心三行：

const init = { method: request.method, headers, body: request.body, signal: request.signal, duplex: 'half', redirect: 'manual' as const }   // :87
const response = await fetch(target, init)          // :88   ← 全局 fetch，不是 net.fetch
...
return new Response(response.body, { status: response.status, headers: outgoing })   // :92

⇒ 你引的那条 Electron 文档判断是对的：protocol.handle 里做转发应当用 net.fetch，而这里用的是全局 fetch（主进程里的 Node/undici 那套），然后把它的 body 流原样塞进一个新的 Response 交回给 Chromium。

这正好解释你那条不对称：有限长度的响应能过，长连接的 SSE 过不去——因为问题不在"能不能转发"，而在"这条流是不是在 Chromium 自己的网络栈里"。有限响应很快读完并结束；SSE 需要长期保持，跨栈的流就会在渲染进程侧以 net::ERR_FAILED 收场。你观察到的"只有经过 dsh-app:// 转发这一层才失败"正是这条推理的判据。

2. 你的排除工作很有价值

你把"自定义协议特权已注册""直连 HTTP 正常（28,710 字节、SSE 帧格式正确）""Node 侧 getReader() 也能拿到 chunk"都排掉了——这三条恰好把范围压到"转发层的流"上，与我上面读到的代码位置一致。附上代码位置后，这条报告已经可被维护者几分钟内确认。

3. 我建议你补一句到报告里（提高可操作性）

把"应改用 net.fetch"和"不要用新的 Response 重新包裹 body 流（或至少不要在跨栈时包裹）"分开写成两条。因为这两处都可能单独致因：前者让请求走 Chromium 栈，后者保证返回的流与接收方同栈。维护者可以只改一处做 A/B，这比一次性全改更容易定位。

4. 一条提醒

你这台是 0.1.7-rc.2——就是当前最新（tag dsh-v0.1.7-rc.2，npm next 也是它），所以不用先升级，你的现场就是最新代码。⚠️ 另请注意别把环境换成 latest（npm 上它仍停在 0.1.5-rc.3，更旧）：

npm i -g @deepseek-ai/dsh@next      # 当前 = 0.1.7-rc.2

5. 顺带确认一件事

你说"插件 bundle 走同一转发路径且工作正常"——这与上面完全自洽（静态资源是有限长度），所以这条对照不但没有削弱你的结论，反而加强了它。建议在报告里保留这句。