fix(bsk): find the Windows daemon through daemon.json like every other platform - #32
Merged
code-yeongyu merged 2 commits intoSep 30, 2026
Conversation
…r platform On Windows the BrowserSkill daemon publishes its named pipe in daemon.json (sock_path \\.\pipe\bsk-daemon-<hash>), exactly as it publishes the Unix socket elsewhere, and node:net connects to a pipe path the same way. resolveSocket threw "unsupported" before reading that file, so every attached-engine call on Windows failed unless the caller hard-coded the pipe name. The fake daemon fixture now listens on a named pipe on Windows, where a socket file under tmpdir cannot be listened on, so the existing discovery tests exercise the real platform path.
Owner
|
Merged into |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On Windows,
connectBrowserSkill()andbrowser-doctor.mjscould not reach a running BrowserSkill daemon unless the caller passed the pipe name by hand.BskIpcClient.resolveSocketthrew before readingdaemon.json:The daemon already publishes the pipe there. On a Windows machine with bsk 0.3.2 and Chrome connected,
~/.bsk/daemon.jsonreads"sock_path": "\\\\.\\pipe\\bsk-daemon-305fe01ffb83710a", andnode:netconnect()takes that path unchanged. So the fix removes the Windows branch and lets discovery readdaemon.jsonon every platform.Evidence (Windows 11, Node 26.10.0)
new BskIpcClient({ autoStart: false }).call("system.status", {})against the live daemonunsupporteddaemon 0.3.2 browsers chromenode --test test/bsk-ipc-client.test.mjsnpm run test:nodeThe 20 failures left in the full suite fail identically on
mainand have Windows-local causes outside this change (skill frontmatter read with CRLF, symlink and permission checks in native-host registration, macOS-only browser signal fixtures, live tests without a headless shell). No test that passed onmainfails here.Change
src/bsk/ipc-client.js: drop thewin32throw inresolveSocket; discovery, auto-start and retry are unchanged.test/fixtures/fake-bsk-daemon.mjs: on Windows the fake daemon listens on\\\\.\\pipe\\<tmp dir name>, sincelisten()on a socket file under tmpdir fails withEACCESthere. This makes the existing discovery tests run the Windows path; before it, 11 of them failed on setup rather than on the behaviour.CI runs on ubuntu-latest only, so the Windows rows above come from a local run.
Summary by cubic
Fixes Windows daemon discovery so
connectBrowserSkill()andbrowser-doctor.mjscan reach a running BrowserSkill daemon without the caller passing the pipe name by hand.win32throw inresolveSocketso discovery readsdaemon.jsonon every platform; the daemon already publishes the named pipe there.Written for commit 445dc66. Summary will update on new commits.