Clarify Terraform 0.12 Resource Missing Error Messaging

[bflad]

Current Terraform Version

Terraform v0.12.0-beta1

Use-cases

During an apply when Terraform Providers are expecting to create resources and the Terraform Provider either never sets the resource in the Terraform state or incorrectly removes the resource from the Terraform state before returning, it returns this newer messaging:

        Error: Provider produced inconsistent result after apply
        
        When applying changes to aws_kms_alias.single, provider "aws" produced an
        unexpected new value for was present, but now absent.
        
        This is a bug in the provider, which should be reported in the provider's own
        issue tracker.

The unexpected new value for was present, but now absent messaging is likely tailored to when specific attribute values change or are missing. When referring to the whole resource though, it seems to be missing a "what" if you are unfamiliar with the full context of the situation in which this occurs (its referring to the entire resource aws_kms_alias.single being missing in the above).

Proposal

In this particular situation, returning a specific message may be clearer for code maintainers and operators:

        Error: Provider produced inconsistent result after apply
        
        When applying changes to aws_kms_alias.single, provider "aws" unexpectedly
        did not create the resource in the Terraform state. The resource may actually
        be present in your infrastructure, but Terraform is not tracking it and applying
        the configuration again may result in duplicate infrastructure errors. If the
        resource was created in your infrastructure and the Terraform resource
        documentation notes support for import, it is recommended to perform the import.
        
        This is a bug in the provider, which should be reported in the provider's own
        issue tracker.

References

• terraform/terraform/eval_apply.go

  Lines 209 to 216 in 87f1877

  	diags = diags.Append(tfdiags.Sourceless(
  	tfdiags.Error,
  	"Provider produced inconsistent result after apply",
  	fmt.Sprintf(
  	"When applying changes to %s, provider %q produced an unexpected new value for %s.\n\nThis is a bug in the provider, which should be reported in the provider's own issue tracker.",
  	absAddr, n.ProviderAddr.ProviderConfig.Type, tfdiags.FormatError(err),
  	),
  	))

[apparentlymart]

This message was intended to just be copy-pasted verbatim into an issue rather than interpreted by a user (since it's always a provider bug, never user error) but I agree that we could do better at being clearer about what situation this has created for a user in the event it does happen.

Some other errors in the same neighborhood include a sentence saying something like "This invalid result has still been saved in the Terraform state." That wouldn't be true here since this bug specifically prevents it from being saved in Terraform state, but hopefully we can use one of those other similar messages as inspiration for the structure of the message to we can keep the message for users clearly separated from the message to developers. (and, of course, also fix the grammar error while we're there.)

[FernandoMiguel]

any tips on where to look at bugs for
aws_cloudwatch_log_stream.log-stream, provider "aws" produced an unexpected new value for was present, but now absent.
i get quite one of those on several jenkins runs

[camlow325]

any tips on where to look at bugs for
aws_cloudwatch_log_stream.log-stream, provider "aws" produced an unexpected new value for was present, but now absent.

As suggested by the error message, this was an issue in the AWS provider implementation. This issue was submitted to the AWS provider GitHub project and a fix was delivered in AWS provider version 2.48.0.

[bashims]

Seeing this problem with Terraform v0.12.27 and AWS provider v2.70.0

This issue seems to be non-deterministic.

[universam1]

Please improve this error, it is a frequent one happening and hard to debug!

[bflad]

We are considering having terraform-plugin-framework try to catch this problematic provider implementation (resource creation with no errors, but empty state) with hashicorp/terraform-plugin-framework#403. This won't obviate the problem for terraform-plugin-sdk or terraform-plugin-go based providers, but hopefully it nudges folks in a better direction.

[apparentlymart]

FWIW I think along the way somewhere we did at least fix the incorrect grammar in this error message, by handing the "whole object is null" case in a different way. Specifically, it now says something to the effect of "Root resource was present, but now absent", since #21312.

I hesitate to close this just because of that, because I think this was requesting something broader, but I'm not really sure how to decide when this issue is considered "done".

I don't think I want to go so far as to rewrite the message for the end user as the target audience, because it seems like that would then make the message much less useful when pasted verbatim into a bug report as the message suggests. I wonder about going in the other direction instead and just being clear up front that this is not an end-user-actionable error and that the expected action is always to open a bug report, not to try to debug it locally.

With that said, if the SDK and/or framework can potentially have access to more information that allow them to deliver a more end-user-actionable error message in some cases then I think that would be great. I would suggest thinking of the message we're discussing here as Terraform Core's last resort when all of the upstream error checking failed and it just isn't safe to proceed further, and so anything we can do to catch this problem sooner (when we have more context about what's going on and why) is very desirable.

[bflad]

This was implemented long ago for any terraform-plugin-framework based provider implementation and I'm guessing there is no other interest in adjusting the core messaging for the reasons above so closing this to reduce issue noise.