-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cognito User Pool: cannot modify or remove schema items #21654
Comments
the same issue with terraform 0.13.6 and aws provider 3.37.0
|
the same issue with terraform 0.13.6 and aws provider 3.70.0 |
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
1 similar comment
+1 |
Please read the community notes and stop commenting with 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 dont care about the changes suggested by terraform like in my case, you can simply ignore them by adding this to your resource block:
|
The solution to this problem is to add a resource "aws_cognito_user_pool" "pool" {
name = "${local.project_name}_user_pool"
mfa_configuration = "OFF" # todo change later to OPTIONAL
lambda_config {
post_authentication = aws_lambda_function.post_authentication.arn
}
auto_verified_attributes = [
"email",
# "phone_number",
]
username_attributes = ["email"]
password_policy {
minimum_length = 8
require_lowercase = true
require_numbers = true
require_symbols = true
require_uppercase = true
}
schema {
name = "email"
attribute_data_type = "String"
mutable = false
required = true
string_attribute_constraints {
min_length = 1
max_length = 256
}
}
schema {
name = "phone"
attribute_data_type = "String"
mutable = false
required = false
string_attribute_constraints {
min_length = 1
max_length = 256
}
}
} |
Resources could be created with both min and max null on string_attribute_constraints on custom fields, AWS defaults values to 0 and 256 on their side. The problem is, once they are created that way, the are permanently null in states, even if the AWS interface show 0 min and 256 max. Since they are immutable, they can't be fixed with new string_attribute_constraints after they are deployed. That is my current problem, I created with empty string_attribute_constraints so both min and max were blank, and even though AWS used defaults of 0 and 256, terraform state reader still reads them as null, forever causing problems when apply other resources or adding new fields because planning doesn't like null. I tried re-importing, still reads as null on both min and max. Is there no way to avoid this problem caused by null string_attribute_constraints arguments? |
I at first deleted existing pool, and rerun apply command with adding string_attribute_constraints |
Unfortunately it happens without the string_attribute_constraints
Terraform v1.1.2
|
aws_cognito_user_pool.user_pools: Modifying... [id=pool_id] |
Same issue with Terraform v1.3.1 + AWS Provider v4.24.0. Correct behavior should be to trigger replacement of |
@jmcvetta that shouldn't be the correct behavior IMHO. You can go to an existing pool in the console and add attributes without replacing the pool. If you replace the pool, then the ID would change which would cause problems downstream for us, since that's how we bind to it. |
@lsacco-nutreense It looks like in the AWS console one can add schema attributes without replacing the pool; but one cannot modify or remove attributes. So the correct behavior should be to update the |
This comment was marked as duplicate.
This comment was marked as duplicate.
This behavior works, I'm using modules and with that block at the end of the resource inside cognito it works perfect for me |
This is an Issue with AWS Cognito User Pools itself. You cannot change or modify standard attributes after user-pool creation. See their docs -> long story short -> not possible. Especially with App-Clients being already registered or a SAML App using the User Pool ID for the SAML Entity ID its a "pain" and is STILL not being addressed properly by AWS (My change was to change email to muteable after registering a SAML provider). In an corporate environment where you can't manage SAML Apps yourself and already using app-clients and changes to a schema can happen from time to time, its honestly a reason to rethink the decision to use AWS Cognito. For the Terraform Provider it means it's correct to recreate the user pool rather than suggesting an attribute can be replaced during plan phase (which just adds up to the overall confusion). Anyone aware of an issue regarding the general AWS Cognito Behaviour? |
Besides the discussion about not being able to edit the schema attributes, terraform is throwing this error for me even when I haven't changed anything in the |
up + Is there any way to at least import the dynamic schema block? |
This functionality has been released in v5.9.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you! |
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. |
Community Note
Terraform CLI and Terraform AWS Provider Version
Terraform v1.0.6
AWS provider 3.63.0
Affected Resource(s)
Terraform Configuration Files
Expected Behavior
Actual Behavior
Steps to Reproduce
terraform apply
The text was updated successfully, but these errors were encountered: