Repository navigation
Carry a refusal's reason, metadata and request id in the JSON failure - #38
Merged
Merged
Conversation
A call the API refused now fails with the error's code, its ErrorInfo metadata and its request id apart, next to the envelope's code and description in `json`, so a script reads the service account a replayed create is about from `.metadata.serviceAccount` instead of parsing the message. Each key is left out when the API sent none; the envelope's `code` and `description` stay as they were. The human formats say a metadata value under the message, as a refused field is, when the message doesn't name it already.
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.
sdk-rust 0.6.0 exposes the ErrorInfo
metadataof a refused call, and this CLI already pins a revision that has it. Before this change the CLI flattened every SDK error into one string, so a script had to parse the message to learn, for example, which service account a replayedcreate-service-accountis about.Changes
jsonfailures from a call the API refused add three keys aftercodeanddescription. Each is left out when the API sent none:reason: the error code, such asCONFLICT;metadata: what the reason names, such as{"serviceAccount": "organizations/o/serviceAccounts/sa-1"};requestId: the id to quote to support.codestays"failure"anddescriptionis unchanged, so existing scripts keep working. Other failures, such as a local validation error or no credentials, print exactly as before.Human formats: a metadata value the message doesn't already contain is printed under the message as
key: value, the same way a refused field is. The replayed service account create's message already names the account, so its text output doesn't change.How:
api_errorreturns a typedoutput::Refusederror.run_clidowncasts to it and prints aCommandResult::Refused.CommandResultnow builds its JSON by hand, because serde's adjacent tagging can't put extra keys next todescription. The JSON for success and for a plain failure is unchanged, andjson_is_printed_as_it_always_wasstill passes.README: the failure-format paragraph lists the new keys.
Testing
a_service_account_s_client_secret_comes_with_a_noticeadditionally checks that:reason,metadata.serviceAccountandrequestId;a_refusal_s_metadata_the_message_doesn_t_name_is_saidsends a 409 whose metadata names an instance the message doesn't. It checks that:--output tableprints it under the message;requestId.a_refusal_adds_what_the_api_said_to_the_json_failureis a unit test of the envelope, with and without the keys.cargo fmt --check,cargo clippy --workspace --all-targetswith and without--all-features(-D warnings),cargo test --workspace,cargo test -p origincloud-cli --all-features, andscripts/generate.sh --check(current at api@6e3294ac3bab).