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.

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

Consider Framework Diagnostics for Empty State Responses after Resource Create or Update #403

Closed
bflad opened this issue Jul 8, 2022 · 1 comment · Fixed by #406
Closed
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@bflad
Copy link
Contributor

bflad commented Jul 8, 2022

Module version

v0.9.0

Use-cases

A non-trivial amount of terraform-plugin-sdk based providers used a convention of calling the resource read function after the resource create or update functions. While this helped reduce duplicate code with that SDK, it also introduced two classes of subtle bugs:

  • Read functions would typically overwrite all state details for the resource in the response state, potentially having mismatched data from the creation plan based on various remote system behaviors such as eventual consistency. Terraform has special logic to demote these errors in terraform-plugin-sdk based providers to warning logs.
  • Read functions would typically implement (*schema.ResourceData).SetId("") to signal resource removal (the equivalent of (tfsdk.State).RemoveResource() in this framework), which is a recommended practice. When this was called during resource create/update, Terraform will return a practitioner confusing version of the provider produced inconsistent results after apply saying the resource is now null. This applies to both terraform-plugin-sdk and this framework, regardless of potential code deduplication efforts by provider developers.

Rather than having practitioners and provider developers struggle with an incorrect implementation of resource create/update via a potentially confusing Terraform error, the framework can detect this situation and provide more helpful guidance.

Proposal

In the framework server code for resource create and update, check for an empty response state after returning early for any error diagnostics. If it is empty, return a specialized error diagnostic, e.g.

Missing Resource State After Create

The Terraform Provider unexpectedly returned no resource state after having no errors in the resource creation. 
This is always an issue in the Terraform Provider and should be reported to the provider developers.

The resource may have been successfully created, but Terraform is not tracking it.
Applying the configuration again with no other action may result in duplicate resource errors.
Import the resource if the resource was actually created and Terraform should be tracking it.

The code returning this should probably include an additional code comment stating that this is to avoid the potentially confusing Terraform error.

References

@bflad bflad added the enhancement New feature or request label Jul 8, 2022
@bflad bflad self-assigned this Jul 8, 2022
bflad added a commit that referenced this issue Jul 8, 2022
…lementations errantly return no errors and empty state after `Create` and `Update` methods

Reference: #403
@bflad bflad added this to the v0.10.0 milestone Jul 8, 2022
@bflad bflad closed this as completed in #406 Jul 8, 2022
bflad added a commit that referenced this issue Jul 8, 2022
…lementations errantly return no errors and empty state after `Create` and `Update` methods (#406)

Reference: #403
@github-actions
Copy link

github-actions bot commented Aug 8, 2022

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 8, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.