Skip to content

fix: don't print 'Tunnel ready' until proxy URL responds#3

Open
drewr wants to merge 1 commit into
feat/stale-connector-warningsfrom
feat/verify-before-ready
Open

fix: don't print 'Tunnel ready' until proxy URL responds#3
drewr wants to merge 1 commit into
feat/stale-connector-warningsfrom
feat/verify-before-ready

Conversation

@drewr

@drewr drewr commented Jun 20, 2026

Copy link
Copy Markdown
Contributor

Important

This PR depends on #2 and should be merged after it.

Problem

Tunnel ready: was printed as soon as all Kubernetes conditions flipped (connector ready, proxy programmed, etc.), but before Envoy Gateway had finished propagating the xDS config. The tunnel URL would return HTTP 503 for some time after the message appeared, making it look broken to the user.

verify_endpoints was written to handle exactly this but was never called — it had been left dead (visible in the dead_code compiler warnings).

Fix

  • main.rs: call verify_endpoints after hostname resolution, before emitting tunnel_ready / printing Tunnel ready:; pass a render_verify callback so tunnel_verifying/tunnel_verified JSON events still fire for the Go supervisor
  • progress.rs: simplify verify_endpoints — replace exponential backoff (capped at 2s, periodic status every 10s) with a fixed 10s interval; print a status line on every attempt

Resulting output

  ✓ TLS certificate issued (0.0s) [HTTPProxy/tunnel-jflkj]
  ✓ iroh DNS published (0.0s) [Connector/datum-connect-ntggr]
  ✓ connector ready (0.4s) [Connector/datum-connect-ntggr]
  ✓ tunnel accepted (0.8s) [HTTPProxy/tunnel-jflkj]
  ✓ route programmed (0.8s) [HTTPProxy/tunnel-jflkj]
  ✓ origin reachable (0.1s) [http://localhost:8888]
  ○ waiting for tunnel [https://certain-come-k328k...] (0.0s) ... HTTP 503
  ○ waiting for tunnel [https://certain-come-k328k...] (10.0s) ... HTTP 503
  ✓ proxy responding (20.3s) [https://certain-come-k328k...]
Tunnel ready: https://certain-come-k328k.prism.staging.env.datum.net

verify_endpoints was written but never called, causing tunnel_ready to
fire as soon as Kubernetes conditions flipped — before Envoy Gateway
had finished propagating the xDS config and the tunnel was actually
serving traffic.

Fix:
- Call verify_endpoints after hostname resolution, before emitting
  tunnel_ready / printing 'Tunnel ready:'
- Probe the origin first (best-effort, bounded budget) to confirm the
  local service is up
- Then poll the tunnel HTTPS URL on a fixed 10s interval until it
  returns a non-5xx response, printing a status line each attempt
- Only then emit tunnel_ready

Also simplifies verify_endpoints: removes the exponential-backoff inner
loop in favour of the fixed 10s interval the user sees.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant