[prototype] Windows daemon support via named pipes#146
Draft
maplesyzzurp wants to merge 3 commits into
Draft
Conversation
maplesyzzurp
force-pushed
the
feat/windows-daemon-named-pipe
branch
from
3f8c748 to
8c78282
Compare
- Add `interprocess = "2"` as a `[target.'cfg(windows)'.dependencies]` - De-cfg the platform-agnostic HTTP layer (`handle_http_stream`, `read_http_request_line`, `read_http_headers`, `read_http_body`, `parse_request_line`, `write_payload_too_large`) so Windows reuses it - Add `windows_pipe_name` (DefaultHasher, no new deps) and `#[cfg(windows)] serve_forever` binding a GenericNamespaced named pipe via `ListenerOptions` and serving the existing HTTP-over-pipe API - Wire `DaemonCommand::Serve` in main.rs: unix and windows each call `daemon::serve_forever`; other platforms bail with a clear message - Add `#[cfg(windows)] serves_health_over_windows_named_pipe` test that binds a pipe in a thread, connects a client `Stream`, sends a health request, and asserts `HTTP/1.1 200 OK` + `"apiVersion"` in the response - Suppress pre-existing dead-code lint regressions on Windows by gating the unix-only TCP helpers, `DaemonHealthStatus`, and related imports with `#[cfg(unix)]`; gate corresponding tests the same way Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
conversation.id is forwarded verbatim as the harness CLI's --session-id/--resume argument. On Windows the harness resolves to a .cmd shim, so CreateProcessW runs it through cmd.exe, which re-parses the command line; an id carrying shell metacharacters could inject commands. Require letters, digits, '-', '_', or '.' — UUIDs and opaque slugs pass, whitespace and metacharacters do not.
maplesyzzurp
force-pushed
the
feat/windows-daemon-named-pipe
branch
from
14df03c to
2e2dae6
Compare
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
1 participant
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.
Draft / proof-of-concept — not a merge request. Opening for visibility + to get a decision on the approach before investing further (and PRs are frozen until July per CONTRIBUTING).
Summary
Today
coven daemonis Unix-only (coven daemon servebails with "only implemented on Unix-like systems for now"; the whole socket/serve path is#[cfg(unix)]). This prototype makes the daemon serve the existing/api/v1/*API on Windows over a named pipe, socoven daemon serveworks on Windows. The published@opencoven/cli-windowspackage is staged, so Windows support is presumably wanted — this is a starting point.What works (verified)
coven daemon servebinds a named pipe and serves the API; a new#[cfg(windows)]test connects a client and getsHTTP/1.1 200 OKfrom/api/v1/health.cargo build/clippyclean on Windows.cargo test --workspace --lockedgreen (693 + 4 tests, 0 failed);cargo clippyclean.Approach
handle_http_stream+ the request/header/body readers, already generic overRead/Write) out of#[cfg(unix)]so both transports reuse it.#[cfg(windows)]named-pipe transport using theinterprocesscrate (windows-only dep). Pipe name is derived fromCOVEN_HOME(hashed) so each home gets a stable, unique pipe.#[cfg(unix)]to keep the Windows build warning-clean.Deferred (NOT in this prototype)
kill/kill -0).PipedKillerusessetsid+kill(-pid, SIGKILL)); Windows needs a Job Object /TerminateProcessequivalent.Open question for the maintainer
The new
interprocessdependency (windows-only) is the key decision. Acceptable? Or would you prefer rawAF_UNIX(Win10 1803+ supports it) or a different transport abstraction? Happy to adjust — that's why this is a draft.Closes part of the Windows-support gap; full parity is follow-up work.