Cognito User Pool standard attribute handling changed in 1.13

[jyrkiput]

I want to set standard attribute as required, and 1.13 forward handling of this changed.

Terraform Version

Terraform v0.11.7

• provider.aws v1.14.1

Affected Resource(s)

aws_cognito_user_pool

Terraform Configuration Files

provider "aws" {
  version = "1.14.1"
}

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

  schema {
    attribute_data_type = "String"
    name                = "phone_number"
    required            = true
  }
}

Debug Output

https://gist.github.com/jyrkiput/4b92d037fcbbb327abb8ddbfeaa5f49c

Expected Behavior

With AWS provider 1.12, you can apply this configuration multiple times without destroying user pool.

Actual Behavior

Terraform things that schema has changed as the string_attribute_constraints is not present

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply
2. terraform apply

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

• Adding custom cognito user pool attribute forces new resource #3891 has comments about similar issue
• Cognito User Pool gets recreated every time when string_attribute_constraints aren't defined #4227 is similar but with custom attribute

Workaround

Define string_attribute_constraints exactly like it seems to be (values found from plan output).

provider "aws" {
  version = "1.14.1"
}

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

  schema {
    attribute_data_type = "String"
    name                = "phone_number"
    required            = true

    string_attribute_constraints {
      min_length = 0
      max_length = 2048
    }
  }
}

[Puneeth-n]

@jyrkiput So if I understood you right, you want to set the phone_number as required and earlier it was not required?

At least from the aws console there is no way of switching an attribute's required attribute once the pool is created. So I am guessing this is the actual behavior. However, I am afraid that setting the string_attribute_constraints seems to be some other bug.

@bflad What do you think?

[jyrkiput]

@Puneeth-n the phone_number has been required from the beginning. With 1.12 you can create this setup and apply it again, with 1.13+ terraform apply start to replace whole user pool.

What I did was:

1. created a new user pool with that configuration with terraform apply
2. ran terraform apply again and user pool got replaced

Actually minimal configuration is following

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

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

This will cause the user pool to be recreated on every terraform apply, as the "phone_number" attribute changes.

I guess that this might really be as expected, as the schema does not really represent what that phone_number -attribute really is.

The reason for creating this issue was that this used to work with 1.12.

[Puneeth-n]

I could reproduce this bug with the following minimal configuration:

variable "region" {
  default = "us-east-1"
}

provider "aws" {
  version               = "1.14.1"
  region                = "${var.region}"
}

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

  schema {
    attribute_data_type = "String"
    name                = "phone_number"

  }
}

My best guess is, it is coming from https://github.com/terraform-providers/terraform-provider-aws/blob/74a51650b29c53a389a9d034c2ece43d3fb279d5/aws/structure.go#L2750-L2756

[bflad]

In 1.13.0 (#3789 specifically), the aws_cognito_user_pool resource was updated to detect schema drift from the API. The initial implementation of this detection was able to wholesale detect changes with schema attributes, but not fully ignore Terraform configurations missing parts of a schema configuration like string_attribute_constraints.

The logic is here:

https://github.com/terraform-providers/terraform-provider-aws/blob/74a51650b29c53a389a9d034c2ece43d3fb279d5/aws/structure.go#L3005-L3018

The workaround is to fully specify all the standard schema attribute information.

[loivis]

Hit the same issue a few days ago. Just workaround it but didn't get time to look into it.

[smastrorocco]

Hitting the same issue Terraform v0.11.7 AWS provider v1.16.0

[haidaraM]

Same issue with Terraform v0.11.8 and provider.aws v1.39.0. Terraform always tries to recreate the user pool even when nothing changed. Example (run terraform apply twice):

resource "aws_cognito_user_pool" "my_user_pool" {
  name                = "${var.prefix}-tuto-cognito"
  username_attributes = ["email"]

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

[huihe]

I got the same issue with Terraform v0.11.11 and provider.aws v1.52.0. New custom attribute results re-creating the user pool.

[codyseibert]

Same issue with Terraform v0.11.11 and provider.aws v1.58.0.

[sa-shukla]

I am also running into same issue with Terraform v0.11.8 and provider.aws v2.x . Is there a proper workaround or fix available in later versions?

[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!

[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.