You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Run terraform apply -refresh-only -auto-approve -input=false -lock=false -json
Current Behavior
Fails with Error reading form_field: <form-field-id>
Expected Behavior
Refresh removes the form_field that was deleted so that it will be recreated.
Cause
I believe I've identified a problem with error handling that's causing this issue.
The generated client code is catching RequestErrors returned by the API, and returning a new error. i.e. currently:
iferr!=nil {
returnnil, errors.Errorf("Error building request: %s", err.Error())
}
In the generated resources e.g. provider/resource_form_field.go
item, err:=c.GetFormField(d.Id())
iferr!=nil {
// In the case of a NotFoundError, it means the resource may have been removed upstream// We just remove it from the state.if_, ok:=err.(client.NotFoundError); ok&&!d.IsNewResource() {
tflog.Warn(ctx, fmt.Sprintf("FormField (%s) not found, removing from state", d.Id()))
d.SetId("")
returnnil
}
returndiag.Errorf("Error reading form_field: %s", d.Id())
}
Since a new error is being returned in the client code, this type assertion will always fail: err.(client.NotFoundError)
The text was updated successfully, but these errors were encountered:
ermul
added a commit
to ermul/terraform-provider-rootly
that referenced
this issue
Feb 26, 2025
Motivation
Primarily meant to resolverootlyhq#73 but the underlying bug may be causing
other unexpected behavior as well.
Problem
The generated client code catches errors and then creates and returns new errors
using errors.Errorf(...).
The generated resources and other consumers of the generated clients catch the
exceptions returned by the generated client methods and branch control flow
based on the result of conditional type assertions w/ `client.RequestError`
and `client.NotFoundError` which are API response types.
Since the errors returned by the generated clients are never
`client.RequestError` or `client.NotFoundError` the conditional type assertions
always fail which prevents the expected error handling code from executing.
In this case of rootlyhq#73, the logic to handle out-of-bounds resource deletion is
there, but is never being executed due to the type assertion failing when
we would want it to succeed.
Solution
At a high level this changes updates the code to use wrapped errors so that
clients can add additional context to errors before they're returned without
preventing consumers from accessing details from the underlying error.
- Update generated client code to wrap errors with `fmt.Errorf` and `%w`
- Update consumers to use `errors.Is` which supports wrapped errors.
- Implemented `Is(error) bool` for `client.NotFoundError` to return true
when the HTTP Status Code of a (potentially wrapped) `client.RequestError`
is 404.
fixesrootlyhq#73
Steps to Reproduce
I'm using
rootly_form_field
here, but I expect it could be reproduced with any resource.versions:
terraform: 1.9.8
terraform-provider-rootly: 2.19.1
form_field
resource (Copied fromexamples/resources/rootly_form_field/resource.tf
and added anoutput
for the ID)form_field
via APIterraform apply -refresh-only -auto-approve -input=false -lock=false -json
Current Behavior
Fails with
Error reading form_field: <form-field-id>
Expected Behavior
Refresh removes the
form_field
that was deleted so that it will be recreated.Cause
I believe I've identified a problem with error handling that's causing this issue.
The generated client code is catching
RequestError
s returned by the API, and returning a new error. i.e. currently:In the generated resources e.g.
provider/resource_form_field.go
Since a new error is being returned in the client code, this type assertion will always fail:
err.(client.NotFoundError)
The text was updated successfully, but these errors were encountered: