Uh oh!
There was an error while loading. Please reload this page.
fix(home): realistic heartbeat timeout so "· Online" stops flickering to "couldn't confirm" - #358
Merged
Merged
Conversation
LukasWodka
commented
Jul 20, 2026
ContributorAuthor
@BugBot run |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 901550a. Configure here.
… flickering `tb`/`tracebloc` flickered between "· Online" and "running — couldn't confirm it's connected to tracebloc" on identical back-to-back runs against a healthy environment. The home heartbeat probe (realHeartbeat -> GetClient) is a backend round-trip, and every invocation is a fresh process, so it pays a cold DNS+TCP+TLS handshake each time — which alone can approach a second. At the old homeProbeTimeout=1200ms / homeDetectBudget=1500ms caps the cold round-trip sometimes overran, yielding beatUnknown -> the alarming "couldn't confirm" even though the client was online. (A flicker proves a timeout, not a persistent client-id/404 issue.) Raise homeProbeTimeout to 3s and homeDetectBudget to 3.5s. The fast path is unchanged — 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. home.go was at its 850-line file-budget ceiling, so bump it to 855 for the added rationale comment (home.go is a split candidate — cli#282 pattern). Fixes#357. Part of epic tracebloc/backend#1142. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
LukasWodka
commented
Jul 20, 2026
ContributorAuthor
@BugBot run |
LukasWodkaforce-pushed
the
fix/home-heartbeat-timeout
branch
from
July 20, 2026 14:03
901550a to
70f9f0cCompareThere was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 70f9f0c. Configure here.
This was referenced Jul 21, 2026
aptracebloc
approved these changes
Jul 21, 2026
Uh oh!
There was an error while loading. Please reload this page.
This was referenced Jul 21, 2026
Merged
saadqbal
commented
Jul 21, 2026
Collaborator
/fr-pass |
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 freeto 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.
Fixes#357 · epic backend#1142.
The bug (Lukas hit it live)
tbflickered Online → couldn't confirm → Online on three identical back-to-back runs against a healthy cluster.Root cause
The home heartbeat probe (
realHeartbeat→GetClient) is a backend round-trip, capped athomeProbeTimeout=1200ms(budget 1500ms). Everytbinvocation is a fresh process → cold DNS+TCP+TLS handshake toapi.tracebloc.ioeach time, which alone can approach ~1s. When the cold round-trip overran 1.2s →beatUnknown→ the alarming "couldn't confirm it's connected." A flicker (sometimes Online) proves it's a timeout, not a persistent client-id/404 issue.Fix
Raise
homeProbeTimeout→ 3s andhomeDetectBudget→ 3.5s. The fast path is unchanged (collectProbesreturns as soon as both probes report), so a quick probe still renders instantly; only a genuinely slow/unreachable backend waits longer — and then "couldn't confirm" is accurate.Note (follow-up, not here)
The same 1.2s cap also bounds the env probe's k8s round-trip (home.go:496,542) — fine for local k3d, but could false-offline a remote customer cluster. Worth a separate look.
gofmt/vet clean; full cli package tests green.
Note
Low Risk
Bounded timeout tuning and a file-budget ratchet bump; no auth or data-path changes, worst case slightly slower home screen when the backend is slow.
Overview
Fixes cli#357: the bare
tbhome screen could alternate · Online with couldn't confirm it's connected on healthy clusters.homeProbeTimeoutgoes from 1.2s → 3s andhomeDetectBudgetfrom 1.5s → 3.5s, so a cold backend heartbeat (fresh process, DNS+TCP+TLS) can finish before the probe falls back tobeatUnknown. Comments inhome.godocument that these floors must not be lowered again.collectProbesbehavior is unchanged—fast probes still return as soon as both complete.scripts/file-budget.shraises theinternal/cli/home.goline ceiling 850 → 855 for the added comment block.Reviewed by Cursor Bugbot for commit 70f9f0c. Bugbot is set up for automated code reviews on this repo. Configure here.