Part of epic tracebloc/backend#1142 (Theme B — home connection reporting).
The bug Lukas hit repeatedly.tb flickers between ✓ Secure environment "lukas-test" · Online and ⚠ … running — couldn't confirm it's connected to tracebloc on identical back-to-back runs against a healthy cluster (observed 3× in one minute: Online → couldn't-confirm → Online).
Root cause. The home screen's heartbeat probe (realHeartbeat → GetClient(<active>), internal/cli/home.go:467) is capped at homeProbeTimeout = 1200ms, and the overall detection at homeDetectBudget = 1500ms (home.go:72-73). That heartbeat is a round-trip to the backend — and every tb/tracebloc invocation is a fresh process, so it pays a cold DNS+TCP+TLS handshake to api.tracebloc.io each time, which alone can approach ~1s before the request is even sent. When the cold round-trip exceeds 1.2s → context deadline → beatUnknown → the honest-but-alarming "couldn't confirm it's connected." A flicker (sometimes Online) proves it's a timeout, not a persistent client-id/404 issue.
Fix. Give the heartbeat a realistic budget for a cold cross-internet round-trip — bump homeProbeTimeout to ~3s and homeDetectBudget to ~3.5s. The fast path is unaffected: collectProbes returns as soon as both probes report, so a quick probe still renders immediately; only a genuinely slow/unreachable backend waits longer (and then "couldn't confirm" is accurate). Local env probe stays snappy (a stopped cluster is connection-refused = instant).
Note (separate, not this ticket): the same 1.2s cap also bounds the env probe's k8s round-trip (home.go:496,542) — fine for a local k3d cluster, but could cause false-offline for a remote customer cluster (EKS/AKS). Worth a follow-up.
Part of epic tracebloc/backend#1142 (Theme B — home connection reporting).
The bug Lukas hit repeatedly.
tbflickers between✓ Secure environment "lukas-test" · Onlineand⚠ … running — couldn't confirm it's connected to traceblocon identical back-to-back runs against a healthy cluster (observed 3× in one minute: Online → couldn't-confirm → Online).Root cause. The home screen's heartbeat probe (
realHeartbeat→GetClient(<active>), internal/cli/home.go:467) is capped athomeProbeTimeout = 1200ms, and the overall detection athomeDetectBudget = 1500ms(home.go:72-73). That heartbeat is a round-trip to the backend — and everytb/traceblocinvocation is a fresh process, so it pays a cold DNS+TCP+TLS handshake toapi.tracebloc.ioeach time, which alone can approach ~1s before the request is even sent. When the cold round-trip exceeds 1.2s → context deadline →beatUnknown→ the honest-but-alarming "couldn't confirm it's connected." A flicker (sometimes Online) proves it's a timeout, not a persistent client-id/404 issue.Fix. Give the heartbeat a realistic budget for a cold cross-internet round-trip — bump
homeProbeTimeoutto ~3s andhomeDetectBudgetto ~3.5s. The fast path is unaffected:collectProbesreturns as soon as both probes report, so a quick probe still renders immediately; only a genuinely slow/unreachable backend waits longer (and then "couldn't confirm" is accurate). Local env probe stays snappy (a stopped cluster is connection-refused = instant).Note (separate, not this ticket): the same 1.2s cap also bounds the env probe's k8s round-trip (home.go:496,542) — fine for a local k3d cluster, but could cause false-offline for a remote customer cluster (EKS/AKS). Worth a follow-up.