user pool failing with "Invalid AttributeDataType input" from CDK >1.45.0

[JNeim]

:question: General Issue

So just jumped from 1.44 >> 1.45 this release introduced a change to the Cognito.UserPool changing the requiredAttributes to standard attributes. While I'm in development now destroying and recreating the stack is not a huge deal, but what would be the correct approach to changing this in production as you would be destroying the userPool thus losing your customer credentials/account.

requiredAttributes: {
    fullname: true,
    email: true
}

changed to

standardAttributes: {
    fullname : { required : true },
    email: { required : true }
}

I would expect that that no change would be detected as it should be the same but it's bombing due to a AttributeType to be enum or something close to it (don't have the error in front of me). In a production situation would you just present a bug and skip the version til its fixed? Or what would generally be the best approach to changes like this to resources that can't be destroyed recreated in production due to data loss.

[nija-at]

I would expect that that no change would be detected as it should be the same but it's bombing due to a AttributeType to be enum or something close to it (don't have the error in front of me).

I've reproduced the error -

integ-user-pool: creating CloudFormation changeset...
 0/2 | 14:37:13 | UPDATE_IN_PROGRESS   | AWS::Cognito::UserPool | myuserpool (myuserpool01998219)
 1/2 | 14:37:15 | UPDATE_FAILED        | AWS::Cognito::UserPool | myuserpool (myuserpool01998219) Invalid AttributeDataType input, consider using the provided AttributeDataType enum. (Service: AWSCognitoIdentityProviderService; Status Code: 400; Error Code: InvalidParameterException; Request ID: ef1494ee-cb23-4a15-99a2-6ea2ada52406)
    new UserPool (/Users/nija/workplace/cdk/aws-cdk/packages/@aws-cdk/aws-cognito/lib/user-pool.js:190:26)
    \_ Object.<anonymous> (/Users/nija/workplace/cdk/aws-cdk/packages/@aws-cdk/aws-cognito/test/integ.user-pool.js:7:18)
    \_ Module._compile (internal/modules/cjs/loader.js:1133:30)
    \_ Object.Module._extensions..js (internal/modules/cjs/loader.js:1153:10)
    \_ Module.load (internal/modules/cjs/loader.js:977:32)
    \_ Function.Module._load (internal/modules/cjs/loader.js:877:14)
    \_ Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:74:12)
    \_ internal/main/run_main_module.js:18:47

This is unexpected. CloudFormation claims that updates to the Schema attribute requires no interruption. However, this seems to be not the case.

I'm re-classifying this as a bug.

[JNeim]

Thanks for reproducing and taking some time on this! @nija-at

[nija-at]

@JNeim - I was going to restore the old behaviour but it seems this field is more complex than I originally thought. See my findings here - https://github.com/aws/aws-cdk/issues/8624.

This is a catch-22. The new behaviour breaks existing users (such as yourself), but reverting back to the old behaviour makes the default value of Mutable more confusing.

In the mean time, the best workaround for you is to use property overrides and set the property explicitly to undefined.

[JNeim]

All good since we are in development so we actually were able to just destroy our stack and recreate it and have no issues, but was just concerned in a production situation where you couldn't do that as you would lose all your customer account data. Thanks for providing that workaround as well.

[nija-at]

Pinning this to see if more people come across this, and if it requires a fix. (pinning expiry: 2 weeks)

[donaldpipowitch]

I ran into this as well. I used

requiredAttributes: {
  email: true
}

and tried:

standardAttributes: {
  email: { required: true },
},

but got Invalid AttributeDataType input, consider using the provided AttributeDataType enum.

It works by using

standardAttributes: {
  email: { required: true, mutable: false },
},

[nija-at]

Apologies for that @donaldpipowitch. That was an unintended side effect of that change. I'm glad you got it to work.

[nija-at]

Closing this since the number of people affected is small, and it doesn't look like the stacks were in production.

[donaldpipowitch]

No worries. Thanks for the response.

[dobrynin]

FYI my team also just ran into this.

[ghost]

My team also just ran into this bug. Please re-open and solve.

[masotrix]

Got into this The quoted workaround did not work

I ran into this as well. I used

requiredAttributes: {
  email: true
}

and tried:

standardAttributes: {
  email: { required: true },
},

but got Invalid AttributeDataType input, consider using the provided AttributeDataType enum.

It works by using

standardAttributes: {
  email: { required: true, mutable: false },
},

[ghost]

I also ran into this bug using AWS Amplify. No solution yet.

[DuncanHouston]

I have now also run into this problem after updating Auth. It's on my dev branch, and I can't roll forward or backwards. And I'm uncertain as to what will happen when I push to prod.

[maupeon]

Same error here, not working at all

[pnedelko]

Have the same problem with Amplify.

[GeorgeBellTMH]

Same issue with Amplify....stuck...

[ENT108]

Same here...

[tangytang]

I am still facing this issue as of 31 October 2022.

[ekeyser]

If anyone comes across this, you likely need to delete the user pool and recreate it. Something about CloudFormation / Cognito not allowing modification to attributes once the user pool has been created.

[KiryuuLight]

If anyone comes across this, you likely need to delete the user pool and recreate it. Something about CloudFormation / Cognito not allowing modification to attributes once the user pool has been created.

This worked for me

[Neurion]

After lots of trial and error, I managed to create my pool client via CDK by removing Email from the StandardAttributes. I have Email configured as my only sign in alias.

[rmjwilbur]

After lots of trial and error, I managed to create my pool client via CDK by removing Email from the StandardAttributes. I have Email configured as my only sign in alias.

Thanks @Neurion - that worked for me. I would not have even considered that with the following error message:

Resource handler returned message: "Invalid AttributeDataType input, consider using the provided AttributeDataType enum. (Service: CognitoIdentityProvider, Status Code: 400, Request ID: ...)" (RequestToken: ..., HandlerErrorCode: InvalidRequest) at FullCloudFormationDeployment.monitorDeployment

@ashishdhingra (or someone) please re-open this so it can get fixed?

[pahud]

I am reopening this issue now.

Please help add 👍 on the issue description above to help us prioritize.