Environment: Windows 11, pie serve --no-auth --debug, portable driver (Vulkan backend, Qwen3-0.6B)
Summary:
Daemon inferlets launched via launch_daemon (tested with chat-apc@0.1.0 from RatioThink) bind their port successfully and show as LISTENING in netstat, but every HTTP request to the daemon fails with RemoteDisconnected: Remote end closed connection without response. The connection is accepted and then dropped before any HTTP response is written, regardless of route (/healthz, /v1/models).
Reproduction:
Run pie serve --no-auth --debug
Using pie_client: install_program with chat-apc's prebuilt wasm + Pie.toml, then launch_daemon("chat-apc@0.1.0", 9001) — returns successfully (None)
netstat -ano confirms port 9001 is in LISTENING state
Any HTTP request, e.g., urllib.request.urlopen("http://localhost:9001/healthz"), raises RemoteDisconnected
Possible lead:
In runtime/src/daemon.rs, Daemon::serve:
rustsocket.set_reuseaddr(!cfg!(windows))?;
This disables SO_REUSEADDR specifically on Windows. Since SO_REUSEADDR semantics differ meaningfully between Windows and POSIX, I'm wondering whether this (or the lack of a Windows-appropriate equivalent) is related to the connection being torn down before hyper::server::conn::http1 can serve it.
Secondary finding - no diagnostic output:
Even with RUST_LOG=debug and --debug, no tracing output appears for daemon connections—including the tracing::error!("HTTP connection error: {e:?}") and tracing::error!("Daemon server error: {e}") calls already present in daemon.rs. This made it hard to narrow down further on my end.
I also went through the Pie paper per your suggestion — it gave great context on the inferlet/daemon model, though it doesn't cover platform-specific Windows behaviour, which is what this issue is about.
Question:
Has launch_daemon been verified working on Windows before? Is there a known-good config I might be missing, or is this a genuine platform gap? Happy to run further tests with additional local logging if that would help—just let me know what'd be most useful to capture.
Environment: Windows 11, pie serve --no-auth --debug, portable driver (Vulkan backend, Qwen3-0.6B)
Summary:
Daemon inferlets launched via launch_daemon (tested with chat-apc@0.1.0 from RatioThink) bind their port successfully and show as LISTENING in netstat, but every HTTP request to the daemon fails with RemoteDisconnected: Remote end closed connection without response. The connection is accepted and then dropped before any HTTP response is written, regardless of route (/healthz, /v1/models).
Reproduction:
Run pie serve --no-auth --debug
Using pie_client: install_program with chat-apc's prebuilt wasm + Pie.toml, then launch_daemon("chat-apc@0.1.0", 9001) — returns successfully (None)
netstat -ano confirms port 9001 is in LISTENING state
Any HTTP request, e.g., urllib.request.urlopen("http://localhost:9001/healthz"), raises RemoteDisconnected
Possible lead:
In runtime/src/daemon.rs, Daemon::serve:
rustsocket.set_reuseaddr(!cfg!(windows))?;
This disables SO_REUSEADDR specifically on Windows. Since SO_REUSEADDR semantics differ meaningfully between Windows and POSIX, I'm wondering whether this (or the lack of a Windows-appropriate equivalent) is related to the connection being torn down before hyper::server::conn::http1 can serve it.
Secondary finding - no diagnostic output:
Even with RUST_LOG=debug and --debug, no tracing output appears for daemon connections—including the tracing::error!("HTTP connection error: {e:?}") and tracing::error!("Daemon server error: {e}") calls already present in daemon.rs. This made it hard to narrow down further on my end.
I also went through the Pie paper per your suggestion — it gave great context on the inferlet/daemon model, though it doesn't cover platform-specific Windows behaviour, which is what this issue is about.
Question:
Has launch_daemon been verified working on Windows before? Is there a known-good config I might be missing, or is this a genuine platform gap? Happy to run further tests with additional local logging if that would help—just let me know what'd be most useful to capture.