Uh oh!
There was an error while loading. Please reload this page.
fix(#553): wait out the metrics-server APIService race before helm install - #618
Merged
Conversation
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
…stall
On a freshly created k3d cluster, k3s registers its bundled metrics-server
(and the v1beta1.metrics.k8s.io APIService) shortly AFTER the API server is
ready. `k3d cluster create --wait` gates only on node/serverlb readiness, so
on a slow WSL2/laptop `helm upgrade --install` could render the
resource-monitor DaemonSet in that window and hit its `{{ fail }}` guard,
aborting the entire first install.
Add a bounded, best-effort `kubectl wait` for the metrics APIService before
the helm install (TB_METRICS_WAIT_S, default 120s). If it never registers we
fall through and let the chart's render-time guard produce its actionable
error, so a genuinely missing metrics-server is still caught (issue's
preferred option (a)).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>- metrics APIService probe passes --request-timeout=10s (non-watch kubectl rule) - outer spinner deadline derived from TB_METRICS_WAIT_S (+60s slack) so a configured wait >180s is no longer silently truncated - regenerate scripts/manifest.sha256 for the changed install-client-helm.sh Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
divyasinghdsforce-pushed
the
fix/553-metrics-apiservice-wait
branch
from
August 6, 2026 10:36
f09595e to
a5f5e05CompareThere was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit a5f5e05. Configure here.
Uh oh!
There was an error while loading. Please reload this page.
… stays fast
The unconditional _wait_for_metrics_apiservice poll loop sleeps 3s up to
${TB_METRICS_WAIT_S:-120}s. In the mocked install_client_helm bats tests
kubectl isn't stubbed, and on the CI runner it isn't installed at all — the
`kubectl get` just fails instantly, so the loop still burns its full deadline
every test, blowing the 10-min job cap (Bugbot #618, CID 3728079502).
Gate the wait exactly like the neighbouring network-y step
_download_services_progress: no-op when TB_NO_SERVICE_PROGRESS is set (the
bats suite sets it in setup()) or when kubectl is unavailable. Real installs
set neither and always have kubectl, so the wait is unchanged for them.
Regen manifest.sha256.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>saadqbal
approved these changes
Aug 6, 2026
Uh oh!
There was an error while loading. Please reload this page.
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.

Closes#553.
Fix
Bounded, best-effort
kubectl waitfor the metrics APIService before helm install (TB_METRICS_WAIT_S, default 120s). The templatefailguard still catches genuine misconfig; this only removes the first-install race.Files
scripts/lib/install-client-helm.shValidation
bash -n.🤖 Generated with Claude Code
Note
Low Risk
Installer-only timing and test guards; no auth, data, or cluster config changes beyond avoiding a flaky first Helm render.
Overview
Fixes a first-install race on fresh k3d clusters: k3s registers the bundled metrics-server (
v1beta1.metrics.k8s.io) after the API is ready, but Helm can render the resource-monitor DaemonSet in that gap and fail the whole install when the chart’s render-time guard fires.The installer now runs a bounded, best-effort wait (
_wait_for_metrics_apiservice, defaultTB_METRICS_WAIT_S=120) with a spinner beforehelm upgrade --install. If the APIService never shows up, install continues so the chart can still surface a real misconfiguration. The wait is skipped whenTB_NO_SERVICE_PROGRESSis set orkubectlis missing so mocked bats runs don’t burn CI time.scripts/manifest.sha256is updated for the changed script.Reviewed by Cursor Bugbot for commit d7ff4fd. Bugbot is set up for automated code reviews on this repo. Configure here.