Provision Query API endpoint lazily instead of at service create#243
Merged
Conversation
The query endpoint upsert returns 500 "Internal error" while a service is still provisioning, so the create-time auto-provision hook always failed and told the user to retry later (#242). `service create` now polls the service state (every 5s, up to 10 minutes) and only enables the endpoint once the service is ready, with state transitions printed to stderr instead of a silent hang. Also stop leaking the dedicated API key when the endpoint binding fails: it is deleted (best-effort) so each retry no longer leaves an orphaned key in the org. Fixes #242 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
iskakaushik
approved these changes
Jun 9, 2026
A freshly created service is still provisioning, so the create-time endpoint upsert either blocked for minutes or failed with 500. Rather than waiting in `service create`, drop the create-time hook entirely: the endpoint is provisioned on first `cloud service query`, which was already the behavior for --json/agent output and for pre-existing services. `service create` now returns immediately and prints a hint that the endpoint is provisioned on first use. The now-meaningless `--no-enable-query` flag is removed (`service query --no-auto-enable` still opts out of the lazy path). The orphaned-key cleanup in ensure_service_query_setup stays. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
iskakaushik
approved these changes
Jun 9, 2026
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.
Fixes #242
Problem
chctl cloud service create --name testhung for a long time and then printed:The control plane returns 500 "Internal error" on the query endpoint upsert while the service is still in
provisioningstate — which a freshly created service always is. By the time the user rancloud service query, the service was running, so the lazy provisioning path succeeded.Fix
Drop the create-time provisioning hook entirely and rely on lazy provisioning at first
cloud service query:--json/agent-detected output and for pre-existing services — so this makes human-modeservice createconsistent with everything else instead of adding wait/progress/Ctrl+C machinery around a multi-minute block.service createnow returns as soon as the API call completes and prints acloud service queryexample plus a note that the endpoint is provisioned automatically on first use.--no-enable-queryflag onservice createis removed since there is no create-time hook left to skip.cloud service query --no-auto-enableremains the opt-out for the lazy path.ensure_service_query_setupno longer leaks the dedicated API key when the endpoint binding fails — the just-created key is deleted (best-effort) before the error propagates, so failed attempts no longer orphan one key each in the org.Testing
cargo test -p clickhousectl: 358 passed.cargo clippy --all-targets: clean.service queryagent help text updated to describe lazy-only provisioning.🤖 Generated with Claude Code