Skip to content

feat: add --wait flag to cluster key create command#73

Merged
Davidonium merged 7 commits intomainfrom
feat/cluster-key-create-wait
Mar 27, 2026
Merged

feat: add --wait flag to cluster key create command#73
Davidonium merged 7 commits intomainfrom
feat/cluster-key-create-wait

Conversation

@qdrant-cloud-bot
Copy link
Copy Markdown
Contributor

Summary

  • Adds --wait, --wait-timeout, and --wait-poll-interval flags to cluster key create
  • After creating the key, when --wait is passed, the CLI fetches the cluster endpoint via GetCluster and polls it with HTTP GET using the new API key until the cluster accepts it (HTTP 2xx), confirming the key has propagated
  • Adds waitForKeyReady generic polling helper to wait_helpers.go that accepts a probe function, following the same context.WithTimeout + time.NewTicker pattern used by waitForHealthyWithInterval

Why

API key creation via the cloud management API is not transactional — it takes time for the key to propagate to the actual Qdrant cluster. Without --wait, scripts that create a key and immediately use it will get auth errors.

Flags

Flag Default Description
--wait false Wait for the API key to become active on the cluster
--wait-timeout 1m Maximum time to wait
--wait-poll-interval 1s (hidden) Polling frequency

Example

qcloud cluster key create abc-123 --name my-key --wait

Test plan

  • TestKeyCreate_NoWait — without --wait, GetCluster is never called
  • TestKeyCreate_WaitSuccess — httptest server returns 403 twice then 200; command succeeds, stderr contains "API key is active"
  • TestKeyCreate_WaitTimeout — httptest server always returns 403; command errors with "timed out"
  • TestKeyCreate_WaitNoEndpointGetCluster returns no endpoint; command errors with "no endpoint URL"
  • TestKeyCreate_WaitDefaultPort — verifies the cluster endpoint is actually probed
  • All pre-existing tests continue to pass

Made with Cursor

Qdrant Claw added 7 commits March 27, 2026 10:39
API key creation is not transactional — it takes time for a newly created
key to propagate to the Qdrant cluster. The --wait flag polls the cluster's
REST endpoint using the new key until it gets a successful response,
confirming the key is active.

Flags added:
- --wait: opt-in to waiting for key activation
- --wait-timeout (default 1m): maximum time to wait
- --wait-poll-interval (default 1s, hidden): polling frequency

Made-with: Cursor
- Suppress errcheck on best-effort resp.Body.Close() in probe
- Remove unused *httptest.Server return from test helper

Made-with: Cursor
A key can be created before the cluster has an endpoint (e.g. cluster
still provisioning). Instead of failing early when no endpoint exists,
the probe now calls GetCluster on each poll iteration and keeps retrying
until the endpoint appears and the key is accepted.

Made-with: Cursor
- Make HTTP error in probe more descriptive: include status code and URL
- Use standard Go error-first checking in waitForKeyReady (if err != nil
  + continue) instead of positive nil check
- Print the probe error in the progress message so users can see why the
  key is not yet active (e.g. no endpoint, HTTP 403, etc.)

Made-with: Cursor
Replace http.DefaultClient with a purpose-built client configured
outside the closure with explicit timeouts (10s overall, 5s TLS
handshake, 5s response header).

Made-with: Cursor
The per-request context already carries the user's --wait-timeout
deadline. A separate client-level Timeout is redundant and could
confuse readers. Transport-level timeouts (TLS handshake, response
header) are kept since they guard specific connection phases.

Made-with: Cursor
@Davidonium Davidonium merged commit 5a412b6 into main Mar 27, 2026
7 checks passed
@Davidonium Davidonium deleted the feat/cluster-key-create-wait branch March 27, 2026 11:19
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