[Bug]: T3 Connect managed endpoint provisioning fails for Windows environment #13681

Activity

1. juliusmarminge commented on Sep 25, 2026

   

   juliusmarminge

   on Sep 25, 2026

   Member

   More actions

   Triage: this is a relay provisioning failure, not a Windows client or cloudflared install failure. The report is specific enough to investigate, and it is not a duplicate of the open Connect PRs.

   POST /v1/client/environment-links returned environment_link_unavailable / managed_endpoint_provisioning_failed. That string is only produced when ManagedEndpointProvider.provision fails (infra/relay/src/http/Api.ts). By the time that runs, the link proof has already verified, the challenge nonce has been consumed, and the origin has passed the loopback check. A bad proof, a non-loopback origin, an insecure endpoint, or the managed-tunnel cap would be different codes (environment_link_proof_*, origin_not_allowed, endpoint_not_secure, environment_link_limit_exceeded).

   That also explains Account → T3 Connect. The environment link row is written only after provision returns (EnvironmentLinker.link). A failure here leaves no registration to deregister. Local cloudflared 2026.5.2 is not on this path either: the desktop checks the binary before the link request, and the connector is started only after the relay returns a tunnel token.

   What this rules out:

   • Missing relay config. That is managed_endpoint_not_configured. The same account provisioned a Linux ARM64 environment on 0.0.42 about a minute earlier, so the base domain and namespace were working.
   • The per-account tunnel cap (default 3). A cap hit says how many tunnels are allowed and tells you to unlink one. Two linked environments (existing Linux desktop plus the new VPS) are under that cap, and "four connections" on the VPS tunnel are connector replicas, not four environments.
   • A 9s relay deadline. That response is a 504 relay_request_deadline_exceeded, not this error.
   • Open follow-ups that only matter after a link exists: fix(desktop): re-register Connect tunnel origin after backend port hop #12724 (re-register origin after a port hop), fix(server): use listener port for managed tunnel origins #8353 (listener port in the link proof), fix(server): wait for Cloudflare tunnel registration #8352 (wait for Registered tunnel connection), chore(shared): bump managed cloudflared to 2026.10.0 #11184 (bump managed cloudflared). None of those run before this response. No managed_endpoint_provisioning_failed issue exists, and nothing on main since v0.0.42 changes this failure path. 0.0.42 is still the latest stable release.

   The client drops the failure stage. The relay error carries stage plus hostname, tunnel name, and tunnel id when it has them. Stages are derive-environment-hash, check-tunnel-limit (a limit-query persistence error, not the cap), reserve-allocation, ensure-tunnel, validate-tunnel-response, record-tunnel, configure-tunnel, ensure-dns-record, record-dns, get-tunnel-token, and mark-allocation-ready. The provision span is relay.managed_endpoint_provider.provision, annotated with relay.environment_id, relay.managed_endpoint.origin_host, and relay.managed_endpoint.origin_port.

   Please look up both traces in t3-code-relay-traces-prod before changing code or resetting the environment id. A new environment id would only hide a wedged allocation for fe3edb38-93ab-415d-88e6-3f761985dd1c.

   • 9a7ec73c7760cf473ffa0468a4e90ce6 (first attempt)
   • ba420157f77192d48966318ef88cc73f (retry, ~2026-09-25 20:47 UTC)

   The retry failing with a new trace means this is sticky to that environment, not a one-off Cloudflare blip and not evidence that Windows in general cannot provision. The stage distinguishes a Cloudflare create/config/DNS error for that hostname from a stuck relay_managed_endpoint_allocations row whose generation claim no longer matches.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 25, 2026
3. thatmike1 commented on Sep 25, 2026

   

   thatmike1

   on Sep 25, 2026

   Author

   More actions

   Update: the reporter retried enabling T3 Connect in Windows Settings and it now works.

   The installed Windows app is still 0.0.42 (file version 0.0.42.0), and v0.0.42 remains the latest stable release. No local app update, environment-ID reset, or allocation cleanup was performed during this investigation. The cause of the recovery is unconfirmed; I cannot tell whether provisioning recovered on its own or was repaired server-side.

   Thanks for the detailed triage. Closing because the reported failure is no longer reproducible for this environment; the trace IDs remain above if useful for investigating the original cause.
4. thatmike1

   closed this as completedon Sep 25, 2026