Observed

In a fresh work up run using Portless on macOS, the routed web wrapper exited before starting Astro. Its log ended with Proxy failed to start (timed out waiting for it to listen). The proxy log repeatedly showed EADDRINUSE on [::1]:1355 and 127.0.0.1:1355, while an existing Portless process was listening on that port. Retrying the wrapper repeated the timeout. Running Astro directly on loopback stayed healthy.

Source report and run details: https://github.com/SynTwin/mono/issues/1076#issuecomment-5851024974

Expected

A new Portless app invocation should attach to a compatible proxy already listening on the configured port. If the listener is incompatible or its configuration cannot be determined, fail promptly with a specific diagnostic rather than spawning a second proxy and timing out.

Relevant code in 0.14.0

ensureProxyRunning tests isProxyRunning(proxyPort, tls) before spawning proxy start; that probe requires a successful HEAD request with x-portless: 1. The explicit PORTLESS_STATE_DIR path also checks whether the port is listening.

I tested a separate HTTP/HTTPS config mismatch with an isolated Portless proxy. That case correctly returned an immediate "Proxy is already running ... with a different config" error, so it does not explain this report. I have not reproduced the exact QA state independently; the macOS log establishes the occupied Portless port and startup timeout. Could proxy discovery report why it failed to recognize the existing listener before spawning another proxy?

written with GPT-6 in Codex

Activity

No activity yet.