Implement d.IsNewResource() Checks In Resource Read Functions

[bflad]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

During resource creation, Terraform CLI expects either a properly applied state for the new resource or an error. To signal proper resource existence, the Terraform Plugin SDK uses an underlying resource identifier (set via d.SetId(/* some value */)). If for some reason the resource creation is returned without an error, but also without the resource identifier being set, Terraform CLI will return an error such as:

Error: Provider produced inconsistent result after apply

When applying changes to aws_sns_topic_subscription.sqs,
provider "registry.terraform.io/hashicorp/aws" produced an unexpected new
value: Root resource was present, but now absent.

This is a bug in the provider, which should be reported in the provider's own
issue tracker.

A typical pattern in resource implementations in the Create/CreateContext function is to return the Read/ReadContext function at the end to fill in the Terraform State for all attributes. Another typical pattern in resource implementations in the Read/ReadContext function is to remove the resource from the Terraform State if the remote system returns an error or status that indicates the remote resource no longer exists by explicitly calling d.SetId("") and returning no error. If the remote system is not strongly read-after-write consistent (eventually consistent), this means the resource creation can return no error and also return no resource state.

To prevent this type of Terraform CLI error, the resource implementation should also check against d.IsNewResource() before removing from the Terraform State and returning no error. If that check is true, then remote operation error (or one synthesized from the non-existent status) should be returned instead. While adding this check will not fix the resource implementation to handle the eventually consistent nature of the remote system, the error being returned will be less opaque for operators and code maintainers to troubleshoot.

In the Terraform AWS Provider, an initial fix for the Terraform CLI error will typically look like:

func resourceServiceThingCreate(d *schema.ResourceData, meta interface{}) error {
    /* ... */

    return resourceServiceThingRead(d, meta)
}

func resourceServiceThingRead(d *schema.ResourceData, meta interface{}) error {
    /* ... */

    output, err := conn.DescribeServiceThing(input)

    if !d.IsNewResource() && tfawserr.ErrCodeEquals(err, "ResourceNotFoundException") {
        log.Printf("[WARN] {Service} {Thing} (%s) not found, removing from state", d.Id())
        d.SetId("")
        return nil
    }

    if err != nil {
        return fmt.Errorf("error reading {Service} {Thing} (%s): %w", d.Id(), err)
    }

    /* ... */
}

The Resource Lifecycle Retries documentation in the Contributing Guide also shows how to mitigate eventual consistency issues by retrying the remote operation for a short period of time.

To catch existing occurrences of this code problem and prevent it going forward, a semgrep rule will be added, e.g.

  - id: helper-schema-ResourceData-SetId-empty-without-IsNewResource-check
    languages: [go]
    message: Calling `d.SetId("")` should ensure `!d.IsNewResource()` is checked first
    paths:
      include:
        - aws/resource*.go
    patterns:
      - pattern-either:
        - pattern: |
            d.SetId("")
            ...
            return nil
      - pattern-not-inside: |
          if ... {
            if <... d.IsNewResource() ...> { ... }
            ...
            d.SetId("")
            ...
            return nil
          }
      - pattern-not-inside: |
          if <... d.IsNewResource() ...> { ... }
    severity: WARNING

Affected Resource(s)

https://gist.github.com/bflad/2c7a8df73a1e5e42d8d82af847f9f226

References

• aws_s3_bucket_object inconsistently returning "Provider produced inconsistent result after apply" #9725
• aws_backup_selection - inconsistent results #9914
• Error: Provider produced inconsistent result after apply #9987
• Cross-account SNS subscription fails with provider bug message #10225
• Race condition renaming public access blocks #10587
• resource/aws_s3_bucket: Provider produced inconsistent result after apply #11064
• aws_sns_topic_subscription resource produced new value for was present but now absent #11737
• aws_config_configuration_aggregator: Provider produced inconsistent result after apply #11769
• Changing terraform name of policy attachment caused provider bug: "Error: Provider produced inconsistent result after apply" #12127
• Provider produced inconsistent result after apply - aws_vpc_endpoint_route_table_association.s3_vpc_endpoint #12449
• "Provider produced inconsistent result after apply" creating multiple ec2 spot requests #12679
• aws_sns_topic_subscription resource produced new value for was present but now absent #12692
• resource/aws_subnet: an unexpected new value for was present, but now absent. #12829
• Storage Gateway Upload Buffer creates resource but "Provider produced inconsistent apply" #12847
• resource/aws_ec2_transit_gateway_route_table_propagation: Error: Provider produced inconsistent result after apply - resource have been created - and TFE cannot apply again #14043
• The aws_appmesh_virtual_service throws "produced an unexpected new value for was present, but now absent" error. #15084
• Provider produced inconsistent result after apply - aws_vpc_dhcp_options_association.dns_resolver #16142
• r/aws_network_interface_sg_attachment: "Error: Provider produced inconsistent result after apply" #16201
• Provider produced inconsistent result after apply on aws_iam_role_policy_attachment #16247
• Provider produced inconsistent result after apply: aws_secretsmanager_secret #16482
• aws_sns_topic_subscription apply intermittently fails with "Root resource was present, but now absent" error #16695
• aws_config_configuration_aggregator -> "Error: Provider produced inconsistent result after apply" #17139
• aws_storagegateway_upload_buffer produces inconsistent result after apply when created on an Outpost #17809
• resource/aws_ses_template: Provider produced inconsistent result after apply Error on Creation #18103
• aws_cloudwatch_event_rule "Provider produced inconsistent result after apply" #18151

[ellisroll-b]

another form for security groups: resource/aws_security_group: error reading Security Group (sg-xxx): couldn't find resource,
Installed hashicorp/aws v3.65.0 (signed by HashiCorp)

[github-actions]

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.