fix(backend): OmniRoute v3.8.48 starts but all HTTP requests hang indefinitely on Windows

[rdswapnali-ops]

OmniRoute Version

v3.8.48

Installation Method

npm (global)

Operating System

Windows

OS Version

Windows 11

Node.js Version

v24.18.0

Provider(s) Involved

OmniRoute

Model(s) Involved

No response

Client Tool

VS Code Kilo Code Extension

Description

Possibly related to #1389, but this appears to be a different issue.

In #1389 the server never completed startup.

In my case the server starts successfully:

• SQLite initialized
• Background services started
• WebSocket services started
• Port 20128 listening

However, every HTTP request hangs indefinitely and the health endpoint never returns a response.

omniroute doctor reports:

WARN Server liveness:
Server health endpoint returned HTTP no-response and fallback probe failed

Steps to Reproduce

1. Install OmniRoute globally.

npm install -g omniroute

2. Run:

omniroute

3. Wait until startup completes.

4. Execute:

curl -I --max-time 10 http://127.0.0.1:20128/

or

curl http://127.0.0.1:20128/api/monitoring/health

5. Observe that the request never receives an HTTP response and eventually times out.

Expected Behavior

The server should respond normally.

Expected:

HTTP/1.1 200 OK

or

HTTP/1.1 302

The health endpoint should return JSON indicating the server is healthy.

Actual Behavior

The TCP connection is established successfully.

The request is sent successfully.

No HTTP headers or body are returned.

After 10 seconds:

curl: (28) Operation timed out after 10003 milliseconds with 0 bytes received

OmniRoute Doctor also reports:

WARN Server liveness:
Server health endpoint returned HTTP no-response and fallback probe failed

Test Impact

Needs a new unit test

Error Logs / Output

OmniRoute Doctor

OK Config
OK Database
OK Storage/encryption
OK Port availability
OK Node runtime
OK Native binary
OK Memory

WARN Server liveness:
Server health endpoint returned HTTP no-response and fallback probe failed

Summary:
7 ok
10 warnings
0 failures


curl.exe -I --max-time 10 http://127.0.0.1:20128/

curl: (28) Operation timed out after 10003 milliseconds with 0 bytes received


netstat -ano | findstr :20128

TCP    0.0.0.0:20128    LISTENING


node --max-old-space-size=4096
.../node_modules/omniroute/dist/server-ws.mjs

omniroute doctor

OK Config
OK Database
OK Storage/encryption
OK Port availability
OK Node runtime
OK Native binary

WARN Server liveness:
Server health endpoint returned HTTP no-response and fallback probe failed


curl.exe -I --max-time 10 http://127.0.0.1:20128/

curl: (28) Operation timed out after 10003 milliseconds with 0 bytes received

Screenshots

Attached.

Includes:

• OmniRoute Doctor output
• curl timeout
• Startup logs

Additional Context

Environment:

• Windows 11
• Node.js v24.18.0
• npm 11.16.0
• OmniRoute v3.8.48
• Installed globally via npm
• SQLite backend
• VS Code Kilo Code Extension configured to use OmniRoute

Troubleshooting already performed:

• Completely removed OmniRoute
• Deleted ~/.omniroute
• Reinstalled globally
• Fresh database created
• Migration issues resolved
• Encryption configured successfully
• Node version verified
• Port verified
• No firewall issues observed

The issue persists on a completely clean installation.

Validation Plan

After the fix:

omniroute

should successfully return:

curl http://127.0.0.1:20128/api/monitoring/health

Expected:

HTTP/1.1 200 OK

The Kilo Code VS Code extension should also connect successfully to the OmniRoute instance.

[diegosouzapw]

Same signature as #6800 ("porta LISTEN + banner 'running!' ~30–60s antes do HTTP responder"). PR #6892 / bin/cli/utils/pid.mjs:74-91 (merged 2026-07-12) — waitForServer() reclassifies in ready | fast-reject | hanging | not-listening. Hanging (TCP accepts but no HTTP response) reset the grace window.

The fix is in release/v3.8.49. Please reinstall v3.8.49 and revalidate; if it still hangs in v3.8.49, open a new issue (don't close #8654 as dup before the re-test).

[diegosouzapw]

Thanks for the detailed report. I dug into this and here is what I found before asking you to re-test.

What the code shows: the exact symptom you describe (port LISTENING + banner printed, but every HTTP request — curl -I / and curl GET /api/monitoring/health — times out with 0 bytes received) is the known startup-warmup signature tracked in #6800. On this stack the HTTP listener accepts TCP almost immediately, but the Next.js request pipeline is still CPU-bound compiling for 30-60s+ (longer on Windows cold start with antivirus/filesystem watchers), so any request sent during that window hangs and eventually times out. In v3.8.48 (your version) the CLI was already fixed (PR #6892) so it no longer prints "running!" prematurely on a bare TCP accept — but the fix does not make the server respond faster; the request still needs the warmup to finish.

What is already in place on v3.8.48 and later:

• waitForServer distinguishes ready / fast-reject / hanging / not-listening (bin/cli/utils/pid.mjs) — a hanging socket no longer counts toward "ready".
• A HEAD-response guard (fix(api): HEAD requests hang ~6s — response never closes after headers #6400/[BUG] Its not opening #7065, scripts/dev/head-response-guard.cjs) forces HEAD requests to return immediately with Connection: close and zero body once the server is alive — this directly addresses your curl -I probe.
• Raised keepAlive/headers timeouts (fix(api): JetBrains AI Assistant (OpenAI Compatible) fails to connect while Ollama works #7003).

Your evidence used curl --max-time 10, which is well below the documented warmup window (measured 34-71s in #6800), so a 10s timeout would fail even on a perfectly healthy, just-booted server.

To move this forward I need one revalidation that research cannot supply:

1. Upgrade to the latest published release: npm install -g omniroute@latest (currently v3.8.50; the fix set is in since v3.8.48 but re-test on the latest).
2. Start omniroute and WAIT 2-3 minutes after the banner (do not probe in the first minute).
3. Then run with a long timeout: curl -i --max-time 120 http://127.0.0.1:20128/api/monitoring/health.

If it responds (any 2xx/3xx/401 — anything, not just 200), the hang was the warmup window. If it STILL returns nothing after a full 2-3 minute warmup wait on the latest version, please report back — that would be a genuine residual Windows bug and we will reopen/keep this open and investigate the server-side request path directly.

[diegosouzapw]

Closing as stale: the fix direction was provided (this is the known startup-warmup signature tracked in #6800, addressed by PR #6892) and we asked you to re-test on the latest release with a 2-3 minute warmup wait and a 120s timeout (curl -i --max-time 120 http://127.0.0.1:20128/api/monitoring/health). No revalidation came back. If you still hit the hang after the documented warmup on the latest version, comment here and we reopen immediately.