Repository navigation
fix(tls): add https fallback to health/readiness probes for TLS-only listeners - #209
Merged
Merged
Conversation
|
PR automation (bot-owned)
|
✅ READY
Hygiene✅ Deterministic PR hygiene checks passed. |
…listeners When hostname is 0.0.0.0 and tls is configured, port 10100 serves HTTPS-only. proxyIdentityAt used directLocalHttpFetch (http-only TCP) -> timeout against TLS port, causing confirmServiceServing to falsely warn 'no proxy answered'. Added one https:// retry via native fetch with rejectUnauthorized:false per attempt for both proxyIdentityAt (/healthz) and probeReadiness (/readyz). Keeps directLocalHttpFetch bypassing proxy env; https via global fetch. Fixes remote session reconnect loops where repair reported serving:false
yansigit
force-pushed
the
codex/fix-tls-health-probe
branch
from
September 2, 2026 02:29
d165cb0 to
9002fb9
Compare
This was referenced Sep 2, 2026
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.
Summary
Fixes misleading
Service repaired, but no proxy answered on port 10100 within 30swhenhostname=0.0.0.0+tlsis configured. With TLS the main listener is HTTPS-only (Bun.serve({tls})/canonicalServerOrigin -> https://…), butproxyIdentityAtandprobeReadinessinsrc/server/proxy-liveness.tsprobedhttp://127.0.0.1:10100/healthzviadirectLocalHttpFetch(HTTP-onlynode:net, rejectshttps:atdirect-local-http.ts:238). The HTTP probe times out,confirmServiceServinginsrc/service.ts:688returnsok:false, and the user sees the 30s warning even though the proxy is serving on HTTPS.Minimal ponytail fix: on transport failure, one
https://retry via nativefetch(…, {tls:{rejectUnauthorized:false}})for self-signed loopback cert. KeepsdirectLocalHttpFetchHTTP-only (proxy bypass) and respects core-lab boundary / synchronousstartServerwindow (no new imports fromsrc/lab/).Closes the root cause behind the repeated
Reconnecting... waiting for network/OCX service repairrequiringOPENCODEX_API_AUTH_TOKENdance reported in remote session (local).Verification
bun run typecheck— passbun test tests/proxy-liveness.test.ts tests/service.test.ts— 258 pass, 0 failbun test tests/core-lab-boundary.test.ts— 17 pass (no lab import leak, no await before activation window)ocx service repairwithOPENCODEX_API_AUTH_TOKEN=$(cat ~/.opencodex/service-api-token)no longer reports 30s timeout when TLS is enabled;curl -k https://127.0.0.1:10100/healthzreturns opencodex healthz,http://127.0.0.1:10200loopback still serves Codexopenai_base_urlChecklist