Skip to content

fix(bridge): speak for an in-process owner Peer on dsh 0.2.1 - #129

Open
flyingbug2 wants to merge 1 commit into
omdsh-dev:mainfrom
flyingbug2:fix/in-process-owner-peer
Open

flyingbug2 wants to merge 1 commit into
omdsh-dev:mainfrom
flyingbug2:fix/in-process-owner-peer

Conversation

@flyingbug2

Copy link
Copy Markdown

概述 / Summary

在 dsh 0.2.1 上给 Gateway 调用补上 in-process owner Peer:wire stream、invoke、$events/result 三处都带上同一个 Peer。

动机 / Motivation

dsh 0.2.1 把 Peer 变成了每个 Gateway 入口的硬要求(0.2.0-rc.2 还没有这段代码):

// @deepseek-ai/dsh-api-gateway
function assertPeerLive(peer, endpoint) { if (peer.signal.aborted) ... }   // 读 peer.signal
function requireInteractions(peer, endpoint) { if (peer.interactions !== "answer") ... }

openWireStream、prepareInvocation(invoke)、$events/result 都会读 peer.signal,而当前实现传 undefined,于是:

  1. $events / session/follow 一开就崩 → hello.ok 之后立刻 stream-failed + ws.close(1011) → 侧栏无限重连;
  2. 所有 RPC(workspace.create、session.create/list/page)返回 gateway/internal: Cannot read properties of undefined (reading 'signal')。

实测报错(macOS,DSH NEXT 2.0.19-next / 内核 0.2.1-rc.2):

browser bridge: workspace.create failed for "~/.dsh/browser-sessions"
  (gateway/internal: Cannot read properties of undefined (reading 'signal'))

关键点:内核 connection 服务自带 createPeer({ principal, interactions })(注释即 "Create one in-process Peer owned by the Context that read this service"),进程内插件完全拿得到 owner Peer;且 $events/result 只要求同一个对象(client.peer !== peer 判等),不需要与其它客户端共用。

改动内容 / Changes

  • HostConnectionLike 增加可选 createPeer;createSharedFetchHandler().fetch 增加可选 peer。
  • 新增 createBridgePeer(connection):createPeer({ principal: { kind: 'owner' }, interactions: 'answer' }),无 createPeer 的内核返回 undefined(保持旧行为)。
  • RemoteHostApi 与 EventGeneration 各持一个 peer,用于:
    • openWireStream(...) 五参载体的第 4 参(原来是 undefined);
    • 4 处 gateway.invoke({...}) 请求体;
    • $events/result 的 fetchHandler.fetch(request, peer)。
  • 补 2 个测试:有 createPeer 时三处都带上该 Peer;无 createPeer 时保持 undefined。

测试 / Testing

macOS 14/15(arm64 + x64),DSH NEXT 2.0.19-next / 内核 0.2.1-rc.2:

  • pnpm run check:runtime ✅
  • pnpm run typecheck ✅
  • pnpm run test → 394 passed ✅
  • pnpm run build ✅
  • pnpm run test:smoke → Real DSH smoke passed: … V4 browser snapshots … ✅
  • 真机端到端:面板「先概览这个页面」→ 会话成功建在 ~/.dsh/browser-sessions 工作区,browser_snapshot / browser_get_text 返回真实页面内容;宿主日志 workspace.create failed 归零。

影响范围 / Impact

  • dsh 0.2.1+:从「完全不可用」变为可用(wire stream + RPC 都通)。
  • dsh ≤ 0.2.0:无变化 —— createPeer 不存在时 Peer 保持 undefined,与原行为逐字一致。
  • 平台/浏览器:改动只在 bridge 插件侧,与 Chrome / Firefox 扩展无关。

Checklist

  • 已在相关平台实测通过 / Tested on the relevant platforms
  • 已通过 pnpm run build / bash -n scripts/install.sh 等基础检查 / Passed basic checks
  • 文档已同步更新(如需要)/ Docs updated if needed
  • 不包含无关改动 / No unrelated changes included

dsh 0.2.1 makes the Peer a hard requirement on every Gateway entry:
`openWireStream`, `invoke`/`prepareInvocation` and `$events/result` all read
`peer.signal`, so an undefined Peer throws
`TypeError: Cannot read properties of undefined (reading 'signal')`.
The bridge then closes the extension socket with 1011 right after `hello.ok`
(the side panel reconnects forever), and every RPC — `workspace.create`,
`session.create/list/page` — fails with `gateway/internal`.

Mint one in-process owner Peer from the Host Connection service
(`createPeer`, exposed from 0.2.1) and use it for wire streams, `invoke`
requests and the `$events/result` fetch, so the answering Peer is the very
object the stream was opened with. Kernels without `createPeer` (0.2.0 and
earlier) keep the previous behaviour.

Refs: browser-context V4 source kind is already handled on main.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant