Demonstrate broken cognito user pool client #1048
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of your changes
This is not intended to be merged, but just to demonstrate the current broken behavior which is fixed in #1021
Fixes #
I have:
make reviewable test
to ensure this PR is ready for review.How has this code been tested
There are currently three problems with the external name config of the cognito user pool client, which make it extremely difficult, if not impossible, to use this managed resource.
These snippets all come from the uptest logs on this PR.
spec.forProvider.name
that doesn't match the regex AWS expects for the user pool client id (which is[\w+]+
), then you can't even create the resource, because you get a validation error from the workaround added in CognitoIDP[UserPoolClient]: Avoid underlying provider validation failure #762.status.conditions
information is lost, as is done deliberately in the uptest import step to simulate a provider pod restart, the managed resource creates an entirely new resource in AWS, orphaning the original resource. I've seen this behavior in my own AWS account, where I can see both user pool clients in the aws console, and the uptest logs show it happening here (theold-id
annotation is set to the value of the id returned in the originalapply
step.)(it shouldn't have
reason: Creating
)It's now successfully created a second user pool client for the same managed resource.
parameters.name
as the initial value for the terraform id (ignoring the value on the external-name annotation), so there's no way to specify the id used for import. Additionally, for this resourceterraform import
expects an argument that is not the value of theid
for this resource. (bugfix) Fix cognito user pool client orphaned resources #1021 fixes the first part, but I can't think of any way to fix the second part without breaking FullControl functionality.