Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[KeyVault] - Admin LRO error conditions #13632

Closed
5 tasks
maorleger opened this issue Feb 5, 2021 · 0 comments · Fixed by #14168
Closed
5 tasks

[KeyVault] - Admin LRO error conditions #13632

maorleger opened this issue Feb 5, 2021 · 0 comments · Fixed by #14168
Assignees
@maorleger
Labels
Client This issue points to a problem in the data-plane of the library. KeyVault
Milestone
[2021] March

Comments

@maorleger
Copy link
Member

There's some confusion regarding whether errors will always come in the errors field of the service response or whether they show up in statusDetails.

This issue tracks coming up with a strategy that makes sense. Maybe we infer based on the status or maybe we only look at errors.

  • Decide on what makes a "failure" that should throw
  • Use the right fields to track error messages so that they are descriptive and usable
  • Update Backup
  • Update Restore
  • Update SelectiveRestore
@maorleger maorleger added Client This issue points to a problem in the data-plane of the library. KeyVault labels Feb 5, 2021
@maorleger maorleger added this to the [2021] March milestone Feb 5, 2021
@maorleger maorleger self-assigned this Feb 5, 2021
@maorleger maorleger mentioned this issue Feb 8, 2021
Closed
@maorleger maorleger mentioned this issue Mar 8, 2021
Merged
maorleger added a commit that referenced this issue Mar 8, 2021
@maorleger
[KeyVault] - Use status field for LRO error conditions (#14168)
f52d26e 
## What

- Use the status field instead of presence of errors for determining whether the LRO failed
- Unpend the "failed if custom role not guid" test
- Pend the full restore test in live mode

## Why

- Using the status field is more reliable and should be the field to decide whether there's an error. The actual error _might_ come in under statusDetails but the status field should be accurate
- There's a service-issue affecting restores and it's impacting our live test pipeline.

Resolves #13632
@github-actions github-actions bot locked and limited conversation to collaborators Apr 12, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@maorleger maorleger

Labels
Client This issue points to a problem in the data-plane of the library. KeyVault
Projects
None yet
Milestone
[2021] March
Development

Successfully merging a pull request may close this issue.

[KeyVault] - Use status field for LRO error conditions maorleger/azure-sdk-for-js
1 participant
@maorleger