Module version
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
Module version
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:
(*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 theprovider produced inconsistent results after applysaying 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.
The code returning this should probably include an additional code comment stating that this is to avoid the potentially confusing Terraform error.
References
Read()from the end ofCreate()/Update()#277