Repository navigation
Expect a repeated service account create to be refused with CONFLICT - #37
Merged
Merged
Conversation
The API no longer answers a create repeated with the same request id with the account minus its secret: the secret went out with the first answer only, so it refuses the repeat with 409 CONFLICT and names the account to delete. The test now repeats the create with the same --request-id and checks the failure carries the reason, the account's name, what to do and the request id, says nothing about a secret, and was sent once.
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.
The API changed how it answers a
CreateServiceAccountrepeated with a request id it already holds. It used to answer with the account, without its client secret. It now refuses with HTTP 409,FAILED_PRECONDITION, reasonCONFLICT. The message names the account and says to delete it and create a new one, and the ErrorInfo metadata carries the name underserviceAccount.Changes
a_service_account_s_client_secret_comes_with_a_noticenow runsorigin iam create-service-account … --request-id r-1twice. The first run still checks the secret notice. For the second run, the fake answers with the API's 409 body, and the test checks that:CONFLICT,organizations/o/serviceAccounts/sa-1, what to do and the request id;The CLI code doesn't change. Its failure description is the SDK error's text, and that text already names the account.
Follow-up, not in this PR
api_errorincrates/cli/src/sdk/runtime.rsappends each field violation to the description. Once the pinned sdk-rust exposesApiError::metadata, it could append the ErrorInfo metadata the same way, asserviceAccount: organizations/…, when the message doesn't already contain it. That would need an sdk-rust bump, so it is kept out of this PR.Testing
I ran every step in
ci.ymllocally:scripts/generate.sh --check,cargo fmt --check, clippy with and without--all-features,cargo test --locked --workspace,cargo test -p origincloud-cli --all-features, shellcheck andrelease/*.test.sh.