fix: fast-path worker-health to skip CLI bootstrap (#1974)#1977
Merged
Conversation
`vibetuner worker-health` paid the full CLI/app bootstrap (sub-command imports plus load_app_config importing the user's tune.py) before it ever read the streaq health key. On a real deploy that bootstrap takes ~5s, so every probe was killed at the scaffolded healthcheck's 5s timeout and a healthy worker flapped to permanently unhealthy. Move the console entry to a main() that dispatches `worker-health` straight to a lightweight check (config + Redis client only) before the heavy Typer app is imported. The full app, with every command and the user CLI, now lives in vibetuner.cli.root and is still built lazily for all other invocations. The healthcheck returns in well under a second. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
davidpoblador
pushed a commit
that referenced
this pull request
Jun 2, 2026
🤖 I have created a release *beep* *boop* --- ## [10.22.4](v10.22.3...v10.22.4) (2026-06-02) ### Bug Fixes * fast-path worker-health to skip CLI bootstrap ([#1974](#1974)) ([#1977](#1977)) ([ee77f6c](ee77f6c)) * load ProjectConfiguration deploy-config from .env ([#1970](#1970)) ([#1971](#1971)) ([13b67a7](13b67a7)) * negotiate Accept-Language with language-only subtag fallback ([#1973](#1973)) ([#1975](#1975)) ([0738181](0738181)) ### Documentation Updates * warn that backgrounded SSE tabs drop events and document resync ([#1978](#1978)) ([6bb1a91](6bb1a91)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
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 free
to 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.
Summary
Fixes #1974.
vibetuner worker-healthpaid the full CLI/app bootstrap before it ever read the streaq health key. The console script wasvibetuner.cli:app, so importing the CLI package eagerly imported every sub-command and ranload_app_config(), which imports the user's entiretune.py(config,BlobService, rate limiter). On a real deploy that bootstrap takes ~5s, so every probe was killed at the scaffolded healthcheck'stimeout: 5s(ExitCode -1) before the check logic ran, and a healthy worker flapped to permanentlyunhealthy.Fix
This is the issue's suggested fix #1 (lightweight fast path), done at the root cause — the entry point.
vibetuner.cli:main.main()dispatchesworker-healthstraight to a lightweight check before the heavy Typer app is imported.vibetuner/cli/health.pyholds the check: it imports onlyvibetuner.configand a Redis client, then reads thestreaq:{queue}:health:*key. Same exit-code contract as before.load_app_config()) moved tovibetuner/cli/root.py, built lazily.vibetuner.cli.__init__stays tiny and re-exposesapp/AsyncTyperlazily via__getattr__for existing importers.python -m vibetunernow routes throughmain()too, so the fast path applies there as well.pyproject.toml.j2entry point bumped tovibetuner.cli:mainso new scaffolds get the fast path.The healthcheck now returns in well under a second, comfortably inside the existing 5s timeout — no timeout bump needed (issue suggestion #2 left untouched).
Verification
uv run vibetuner worker-healthandpython -m vibetuner worker-healthcomplete in ~0.4s; the fast path does not importvibetuner.cli.root,scaffold, orcopier(verified via a fresh-interpreter regression test).versionand all other commands still build the full app unchanged.Docs
cli-reference.mdnotes the fast-path behavior for ops users tuning healthcheck timeouts.🤖 Generated with Claude Code