feat(cli): show "waking up worker" hint on KEDA cold starts#167
Merged
Conversation
Wrap worker-bound commands in block_with_wakeup: show a spinner and, if the request hasn't returned within ~1.5s, probe the control plane's /v1/workspaces/<id>/runtime/status and upgrade the message when the worker is cold. Warm requests pay nothing — the probe only fires after the delay and is dropped the instant the real response lands. The probe omits X-Workspace-Id so it reaches the always-warm control plane, not the KEDA interceptor. Wired into list/get/create/update/delete/refresh across databases, connections, datasets, tables, context, embedding providers, queries, jobs, indexes, and query execute. Polling loops, pagination, rayon scans, and internal helpers stay on plain block().
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Reviewed: clean implementation. The cold-start probe degrades to Unknown on all failure paths and never affects control flow, the X-Workspace-Id omission is correct and tested, the select loop cancels the probe the moment the real request lands, and the stderr/TTY-gated spinner keeps scripting output clean. Good test coverage.
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
1 participant
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.
What
When a command hits a KEDA scale-to-zero runtimedb worker that's asleep, the request hangs while the worker cold-starts and the user gets no feedback. This adds a spinner that, on a confirmed cold start, explains the wait: "waking up worker after inactivity...".
Pairs with the control-plane endpoint on
monopoly(feat/runtime-status-endpoint), which this probes.How
New
block_with_wakeup(api, msg, fut)insdk.rs:tokio::select!. If the request is still pending past the threshold, it probes the control plane'sGET /v1/workspaces/<id>/runtime/statusand, when the worker isasleep/waking, upgrades the spinner message.X-Workspace-Idso it reaches the always-warm control plane, not the KEDA interceptor (which would wake the worker). Best-effort: any failure ->Unknown-> no message change.Scope
Wired into top-level worker-bound commands: list/get/create/update/delete/refresh across databases, connections, datasets, tables, context, embedding providers, queries, jobs, indexes, plus query execute. Existing spinners were converted (not doubled). Polling loops, pagination, rayon scans, and internal helpers stay on plain
block().Testing
RuntimeStateparsing and the probe (asleep/non-2xx/unscoped), incl. asserting the probe sends noX-Workspace-Id.cargo fmtclean; no new clippy warnings.