Replace verbose azcore errors with more concise ones#3783
Conversation
Does the PR have any schema changes?Looking good! No breaking changes found. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3783 +/- ##
==========================================
+ Coverage 56.65% 56.71% +0.05%
==========================================
Files 78 78
Lines 11975 11999 +24
==========================================
+ Hits 6785 6805 +20
- Misses 4689 4691 +2
- Partials 501 503 +2 ☔ View full report in Codecov by Sentry. |
| return nil, nil | ||
| } | ||
|
|
||
| func newResponseError(resp *http.Response) error { |
There was a problem hiding this comment.
Do we want to call it in shouldRetryConflict too?
There was a problem hiding this comment.
The error in shouldRetryConflict is never shown to the user. We only access its ErrorCode.
|
This PR has been shipped in release v2.78.0. |
Fixes an issue I discovered today when trying to reproduce another issue
report. `pulumi refresh` is broken for this provider:
```
$ PATH="$HOME/pulumi/pan/bin:$PATH" pulumi refresh --skip-preview -s dev
pulumi:pulumi:Stack recoveryservices-protecteditem-dev **failed** 1 error; 4 warnings
~ ├─ azure-native:resources:ResourceGroup resourceGroup **refreshing failed** 1 error
azure-native:resources:ResourceGroup (resourceGroup):
error: Code="ResourceGroupNotFound" Message="Resource group 'resourceGroup3f871416' could not be found."
```
The reason is that #3783 regressed `azure.IsNotFound`, causing `Read` to
report an error when a resource doesn't exist in Azure.
This PR fixes the problem and adds test coverage.
|
A possible follow-up is to handle the final error message of long-running operations, as returned by the poller as an |
This PR fixes an error that occurs in the deletion of a (non-existent) Azure resource. The issue impacts resources that have an async-style DELETE call (as is the case for Subnet, see [schema](https://github.com/Azure/azure-rest-api-specs/blob/1b038fc40563bdafb343a71cd5f7d3dee6bc4b5b/specification/network/resource-manager/Microsoft.Network/stable/2019-02-01/virtualNetwork.json#L396-L399)). The technical detail is that the 404 may come in the initial response as opposed to during polling, and that wasn't handled correctly.. The user-facing error is: ``` azure-native:network:Subnet (subnet): error: the operation failed or was cancelled ``` The call to `runtime.NewPoller` should not be made with a failed response, otherwise we hit a precondition within it: ```go // this is a back-stop in case the swagger is incorrect (i.e. missing one or more status codes for success). // ideally the codegen should return an error if the initial response failed and not even create a poller. if !poller.StatusCodeValid(resp) { return nil, errors.New("the operation failed or was cancelled") } ``` To fix, I encapsulated the request-to-final-response logic into an anonymous function, to be able to uniformly check for the 404 result. And I ensure that the initial response was successful before making a poller. This PR relaxes the logic for detecting a 404 during resource deletion, to not care about the specific error code. I find that at least two codes are possible: `ResourceNotFound` and `ResourceGroupNotFound`. Note that the sync path did not check the error code anyway and a uniform solution is desirable. TODO: - [x] new unit tests - [x] manual testing for various types of resources (w/ sync and async delete operations). Closes #3978 See also: #3783
Fixes #3778
Before:
After: