Cognito User Pool gets recreated every time when string_attribute_constraints aren't defined

[jyrkiput]

Terraform Version

Terraform v0.11.7

• provider.aws v1.14.1

Affected Resource(s)

aws_cognito_user_pool

Terraform Configuration Files

Minimal case

provider "aws" {
  version = "1.14.1"
}

resource "aws_cognito_user_pool" "pool" {
  name = "cognito-terraform-bug"

  schema {
    attribute_data_type = "String"
    name                = "testcase"
  }
}

Debug Output

Both stdout and stderr

https://gist.github.com/jyrkiput/47873e5fba67641175fdd8cc87e6af92

Expected Behavior

Nothing should change and run should complete

Actual Behavior

On second run, Terraform tries to replace user pool as existing attribute changes. Then this change fails with aws_cognito_user_pool.pool: aws_cognito_user_pool.pool: diffs didn't match during apply. This is a bug with Terraform and should be reported as a GitHub Issue.

Steps to Reproduce

1. terraform apply
2. terraform apply

References

• Adding custom cognito user pool attribute forces new resource #3891 talks about similar issue

[github-actions]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

[alex]

As far as I can tell, this issue is still present.

[anGie44]

Hi @jyrkiput, thanks again for creating this issue and apologies you came across this confusing error!

There have been a lot of relevant changes in the Terraform Core and Terraform AWS Provider codebases since this issue was originally reported so as a first step it might be best to try updating to recent versions of both and seeing if any of those updates may have resolved this issue.

Attempting to troubleshoot these types of errors is very difficult in Terraform 0.11 and earlier as those versions will report this problem (diffs didn't match during apply error) where a problematic configuration value exists or is referenced and not where the Terraform resource with the underlying problem actually exists. We typically will need much more information than the original error message suggests for filing the issue (e.g. the full Terraform configuration). There are also frequent issues in the Terraform 0.11 error reporting where the error message is due to behavior outside the control of the Terraform resources themselves (e.g. lifecycle configurations).

In Terraform 0.12 and later, the "value did not match" type of error can now be found with the newer Provider produced inconsistent result after apply error, which better reports the source of the problem so the provider maintainers and community can more easily work towards a fix of the issue. Other similar errors that fell previously into diffs didn't match during apply errors, but outside problems within the Terraform provider are also better diagnosed before being displayed.
Since the majority of the Terraform code path and reporting structure of these errors has changed between Terraform 0.11 and 0.12, along with the difficult triage process in Terraform 0.11 and earlier, the maintainers prefer to close these older issues to continue troubleshooting and fixing based on Terraform 0.12's error reporting instead. I apologize for this unsatisfying closure of this particular version of the issue.

That said, if the configuration does happen to reproduce the newer Provider produced inconsistent result after apply error in Terraform 0.12 (which requires Terraform AWS Provider version 2.7.0 or later), please do not hesitate to file a new issue and complete all of the information requested in the Bug Report template so we can hopefully get to the root cause for fixing the issue. Thanks again for this bug report and sorry about the additional steps.

[ghost]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!