amplify-cli: Add User Migration trigger during `amplify add auth`?

Note: If your question is regarding the AWS Amplify Console service, please log it in the official AWS Amplify Console forum

Which Category is your question related to? auth

Amplify CLI Version 4.21.2

You can use amplify -v to check the amplify cli version on your system

What AWS Services are you utilizing? Cognito, Lambda

Provide additional details e.g. code snippets

How do I configure a User Migration trigger during the setup of a user pool via Amplify? I’m able to create many other triggers (PostAuthentication, PreSignUp, etc.) but not UserMigration.

About this issue

  • Original URL
  • State: open
  • Created 4 years ago
  • Reactions: 2
  • Comments: 19 (4 by maintainers)

Most upvoted comments

From my experience pretty much all cognito triggers require custom logic. And I wish amplify would just set me up with one lambda to handle all cognito triggers instead of doing one lambda per trigger, juggling multiple lambdas and navigating the nested questions of amplify auth update is time consuming. Just some feedback. Perhaps I will get the big picture as amplify cli’s cognito triggers functionality matures more.

To support user migration trigger for now i piggy backed on the pre token lambda trigger and made that the user migration trigger as well by modifying the auth cloud formation.

I have automated adding UserMigration trigger by committing manual modification to auth-trigger-cloudformation-template.json, and it had been working. However, since CLI version 7, this modification is removed and I couldn’t find any workaround. Is there any way to set up UserMigration trigger automatically for CI? Because of this, I cannot upgrade Amplify CLI to version 7.

For what it’s worth, I don’t understand the desire to have a single function handle multiple events. Do one thing and do it well. Lambdas are no different.

Well, we have user migration, pre and post authentication, and pre and post signup events which does similar stuff using AppSync lookups in our database for example. The code required to run these AppSync requests are the same, and by having 6 functions, we have that same code 6 places vs. 1 place if they all resided in the same function.

If Lamda Layers were working well, we could have that shared code in one Layer and multiple functions would be cool, but since Lambda Layers seems to be very very buggy by looking at the number of bug reports and severity of bugs, we have not yet started using that feature.

Another reason to keep it as one function is warm up time. If one function is utilized more often, there’s less chance it’ll go cold and has to start up which adds to the execution time and memoization of for example lookups to the Parameter Store would also be utilized more.

Recently a change to functions and their access in Amplify was changed and broke for some existing users, requiring a manual update to access for all functions. That was a manual task, which becomes tedious and takes more time, by having to update more functions.

Need more? 😉

Yeah, I don’t understand the modules looping either, it’s just over-complexifying stuff that should be a simple boiler template and if it is, thus easy to understand for the end developer, and then the default file created could include some sample code or commented information about triggerSource and a link to documentation about it for Cognito triggers.

Personally I’d prefer using ONE function for all triggers, and then switch the functionality based on the triggerSource. Lambda Layers is still crazy buggy, and since many of these functions will do the same, the overhead in redundant code by creating multiple functions is kinda annoying. Having the option to choose an existing function would be nice also, but I could live with any implementation as long as all triggers are possible to add.

Currently, I’m doing it totally manual. I created a normal function and then in the Cognito UI, I have manually selected the function. This has the risk of the UI being overwritten by a push or a configuration being forgotten, but one gotta do what one gotta do to make stuff work.

How some triggers were added and others left out I don’t understand, but it seems typical with doing things half-ass in Amplify land.

@pikanji How were you able to create the trigger via a custom resource when the User Pool and Lambda functions are managed outside of the Custom stack?

I just tried the same thing myself and found that cognito.UserPool.fromUserPoolArn returns IUserPool which doesn’t actually have the addTrigger method (even tried forcing a cast which failed as well).

@josefaidt Any idea of when this might be supported?

@hanachan1026 found out the way to solve my problem. Using custom category (introduced in v7?), we could successfully let amplify set up UserMigration trigger with our custom cloud formation template. We added custom category and moved our customization to auth-trigger-cloudformation-template.json to the template file under custom category directory.