Problem
clickhousectl cloud service query always auto-provisions a dedicated Query API key when no per-service key is stored in .clickhouse/credentials.json. This happens even when the API key used to authenticate the CLI is already bound to the service query endpoint and can execute the requested SQL.
If that key can query the service but cannot create API keys, the command fails during unnecessary provisioning.
Reproduction
- Create a service Query API endpoint.
- Bind an API key to the endpoint.
- Authenticate
clickhousectl with that key.
- Ensure no per-service key is cached locally.
- Run
clickhousectl cloud service query --id <service-id> --query "SELECT 1".
The CLI attempts to create another API key and fails if the authenticated key lacks key-creation permission.
Expected behavior
When no cached per-service key exists, try the authenticated API key directly against the Query API. If it is accepted, execute the query without provisioning or writing local credentials. Fall back to the existing provisioning flow only when the Query API rejects the key or the endpoint is unavailable.
Keep cached per-service keys preferred when present, and do not provision in response to SQL, transport, rate-limit, or server errors.
Problem
clickhousectl cloud service queryalways auto-provisions a dedicated Query API key when no per-service key is stored in.clickhouse/credentials.json. This happens even when the API key used to authenticate the CLI is already bound to the service query endpoint and can execute the requested SQL.If that key can query the service but cannot create API keys, the command fails during unnecessary provisioning.
Reproduction
clickhousectlwith that key.clickhousectl cloud service query --id <service-id> --query "SELECT 1".The CLI attempts to create another API key and fails if the authenticated key lacks key-creation permission.
Expected behavior
When no cached per-service key exists, try the authenticated API key directly against the Query API. If it is accepted, execute the query without provisioning or writing local credentials. Fall back to the existing provisioning flow only when the Query API rejects the key or the endpoint is unavailable.
Keep cached per-service keys preferred when present, and do not provision in response to SQL, transport, rate-limit, or server errors.