Skip to content

fix(installer): bound services progress-bar kubectl with --request-timeout#351

Merged
saadqbal merged 1 commit into
developfrom
fix/bugbot-345-progress-timeout
Jul 14, 2026
Merged

fix(installer): bound services progress-bar kubectl with --request-timeout#351
saadqbal merged 1 commit into
developfrom
fix/bugbot-345-progress-timeout

Conversation

@saadqbal

@saadqbal saadqbal commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

Summary

Bugbot Medium on #345: _download_services_progress (scripts/lib/install-client-helm.sh) is documented as bounded/non-blocking, but its two kubectl get pods calls omitted --request-timeout. Since the TB_PULL_TIMEOUT deadline is only checked between iterations, a wedged or unreachable API makes kubectl block indefinitely — freezing step e's progress bar before the authoritative readiness gate in step f ever runs.

Fix

Add --request-timeout (default 5s, overridable via TB_PROGRESS_KUBECTL_TIMEOUT) to both kubectl get pods calls, mirroring assess.sh's bounded probe. A call that can't reach the API now returns quickly, the loop re-checks the deadline, and step e degrades to the honest "still downloading in the background" line instead of hanging.

Test plan

  • shellcheck --severity=error scripts/lib/install-client-helm.sh → clean
  • bats scripts/tests/install-client-helm.bats → 53 pass (the one pre-existing _extract_yaml_value '' escape failure is unrelated and also fails on develop); the progress fn is skipped in bats via TB_NO_SERVICE_PROGRESS, so behavior there is unchanged
  • scripts/gen-manifest.sh --check → up to date

Checklist

  • No secrets / credentials in the diff

🤖 Generated with Claude Code


Note

Low Risk
Small, localized installer UX fix with no auth, data, or install-success path changes beyond avoiding a progress-bar hang.

Overview
Fixes a hang in install step e where _download_services_progress could block forever on kubectl get pods when the API is wedged or unreachable. The loop only checks TB_PULL_TIMEOUT between iterations, so unbounded kubectl calls ignored that deadline.

Both pod-list probes now use --request-timeout (default 5s, override via TB_PROGRESS_KUBECTL_TIMEOUT), matching the bounded kubectl pattern in assess.sh. Failed or slow API calls return quickly; the bar can time out and show the “still downloading in the background” path instead of freezing before step f’s readiness gate. The script manifest checksum is updated for the changed installer lib.

Reviewed by Cursor Bugbot for commit b7fb5fa. Bugbot is set up for automated code reviews on this repo. Configure here.

…request-timeout

Bugbot (Medium): _download_services_progress claims to be bounded/non-blocking,
but its two `kubectl get pods` calls omitted --request-timeout. The
TB_PULL_TIMEOUT deadline is only checked BETWEEN iterations, so a wedged/
unreachable API makes kubectl block indefinitely — freezing step e's progress
bar before the authoritative readiness gate in step f ever runs.

Add --request-timeout (default 5s, overridable via TB_PROGRESS_KUBECTL_TIMEOUT)
to both calls, mirroring assess.sh's bounded probe — a call that can't reach the
API now returns quickly, the loop re-checks the deadline, and step e degrades to
the honest "still downloading in the background" line instead of hanging. Manifest
regenerated.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@saadqbal saadqbal self-assigned this Jul 14, 2026
@LukasWodka

Copy link
Copy Markdown
Contributor

👋 Heads-up — Code review queue is at 48 / 30

Above the WIP limit. The team convention is to review existing PRs before opening new work.

Open PRs currently in Code review (oldest first):

Pull from review before opening new work. (This is a nudge from the kanban WIP check, not a block.)

@saadqbal saadqbal merged commit 975d480 into develop Jul 14, 2026
35 checks passed
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.

2 participants