Get apiaivyGraphQLAPIIdOutput in auto generated PostConfirmation Lambda? #1874

davidbiller · 2019-07-20T16:26:02Z

How get apiaivyGraphQLAPIIdOutput in auto generated PostConfirmation Lambda?

i tried function update, and allow access to appSync, but this dosent work, because a dependsOn Failure.

Any infos?

haverchuck · 2019-07-21T01:34:05Z

@davidbiller What exactly is the error you’re seeing?

davidbiller · 2019-07-21T05:16:11Z

It was a circular dependency error.
Should I do it again, and copy the whole error message?

ErickTamayo · 2019-07-22T19:58:25Z

I'm having the same issue when I do amplify update function and add api category access to the lambda post-confirmation trigger:

Ericks-MBP:app Erick$ amplify update function
Using service: Lambda, provided by: awscloudformation
? Please select the Lambda Function you would want to update icontainerPostConfirmation
? Do you want to update permissions granted to this Lambda function to perform on other resources in your project?
 Yes
? Select the category api
Api category has a resource called icontainer
? Select the operations you want to permit for icontainer create, read, update, delete

You can access the following resource attributes as environment variables from your Lambda function
var environment = process.env.ENV
var region = process.env.REGION
var apiIcontainerGraphQLAPIIdOutput = process.env.API_ICONTAINER_GRAPHQLAPIIDOUTPUT
var apiIcontainerGraphQLAPIEndpointOutput = process.env.API_ICONTAINER_GRAPHQLAPIENDPOINTOUTPUT

? Do you want to edit the local lambda function now? No

Then pushing:

Circular dependency between resources: [functionme, authicontainer, functiondeleteDirectory, functionicontainerPostConfirmation, apiicontainer]

edit: here is my backend-config.json https://gist.github.com/ErickTamayo/2fc64c7d886527f968f28c58727be2a7

voidarg · 2019-07-23T17:14:36Z

I second that. Also looking for the way to pass API ID (for the table names) to the postConfirmation lambda.

gchablowski · 2019-08-08T15:00:33Z

Same here, if you give a congnito trigger lambda with amplify update function access to the api there a Circular dependency between resources error that appear when you push. It should be possible to make it work with a custom resource. But I begin with amplify and don't really know where and how to put it.

DanNeish · 2019-08-14T11:36:21Z

I'm also had this problem, but when trying to allow lambda access to auth. I have created a PostConfirmation trigger for cognito auth (through amplify update auth) and want to set the value of a custom cognito attribute for the user when they confirm their account. (using aws-sdk adminUpdateUserAttributes).

? Please select the Lambda Function you would want to update mycognitoPostConfirmation
? Do you want to update permissions granted to this Lambda function to perform on other resources in your project? Yes
? Select the category auth
Auth category has a resource called mycognito
? Select the operations you want to permit for mycognito update

You can access the following resource attributes as environment variables from your Lambda function
var environment = process.env.ENV
var region = process.env.REGION
var authMycognitoUserPoolId = process.env.AUTH_MYCOGNITO_USERPOOLID

Error: Cannot add mycognitoPostConfirmation due to a cyclic dependency
    at checkForCyclicDependencies (/usr/local/lib/node_modules/@aws-amplify/cli/src/extensions/amplify-helpers/update-amplify-meta.js:243:11)
    at Object.updateamplifyMetaAfterResourceUpdate (/usr/local/lib/node_modules/@aws-amplify/cli/src/extensions/amplify-helpers/update-amplify-meta.js:119:5)
    at Object.updateResource (/usr/local/lib/node_modules/@aws-amplify/cli/node_modules/amplify-category-function/provider-utils/awscloudformation/index.js:243:21)
    at process._tickCallback (internal/process/next_tick.js:68:7)

Currently my workaround is to manually edit the auth cloudformation template and add the permissions, however it would be better if we could do this through the cli.

rpostulart · 2019-10-16T19:07:05Z

Is there an update?

I also did a function update and add permissions to API to access the appsyncid.
I need this id in the lamba cognito trigger post confirmation to send a userid to the dynamodb table: tablename-appsyncID-environment

But I received an Circular dependency error

wellini · 2019-10-21T09:49:32Z

Having same issue

rfpedrosa · 2019-11-06T19:46:58Z

+1

patspam · 2019-11-09T10:45:58Z

Any updates?

BabyDino · 2019-11-11T14:16:13Z

Same issue here at the moment. I need the API Id in my CF template. Anyone with a workaround for the time being?

I need the same as @rpostulart, <tablename>-<AppSyncID>-<env>, both in the roles and as an environment variable to target the DB Table.

rahulvyas1 · 2019-11-15T09:35:39Z

I am facing the same issue when updating API and adding a new endpoint

gretchen-blackwood · 2019-11-26T19:58:07Z

I'm having the same issue when adding API access to my postConfirmation function. I tried to update the function again to remove API access, and I still get the circular dependency error. I'm not sure how to undo the issue.

davidbiller · 2019-11-26T20:27:28Z

I'm having the same issue when adding API access to my postConfirmation function. I tried to update the function again to remove API access, and I still get the circular dependency error. I'm not sure how to undo the issue.

Amplify env checkout yourEnvName —restore

grigull · 2019-12-18T01:37:39Z

Alternatively you can search through the cloudformation-template and delete all references to the the post confirmation trigger. I am having the same issue, where i am unable to add access to my graphql api in the post confirmation trigger, the same circular reference occurs.

paulsson · 2020-01-16T17:18:25Z

@kaustavghosh06 any updates on this very common problem? Is there a recommended best practice from the Amplify team to work around this?
Right now, I am updating the IAM role permissions manually to allow my lambda function permission to call my GraphQL api. Manually updating IAM roles is not ideal at all. I don't mind writing CloudFormation to do this but it is not clear how to tie in a custom child CloudFormation template into the Amplify backend CloudFormation template/stack hierarchy.
Having documentation for Amplify that shows how to update IAM roles with custom policy statements would be very beneficial for everyone using Amplify and could solve this problem scenario as well as others.
Thoughts?

Thanks,
Erik

amuresia · 2020-01-17T22:10:17Z

+1

dtelaroli · 2020-01-20T16:12:30Z

+1

mdebo · 2020-01-21T10:04:38Z

+1

martinjuhasz · 2020-01-29T12:36:15Z

+1 didn't find a good solution yet. would love to get some hints on how to do this correctly. I guess one must create a custom resource and bind both api and postConfirmation function to those as dependencies? not sure tho.

dylan-westbury · 2020-08-31T23:49:50Z

A work around for us, we added the graphql ids to out cloudformation which allows us to get the table name and access it by process.env.USER_TABLE_NAME.

Additions to the cloudformation template are Mappings, Variables and the dynamodb:putitem arn permissions policy under lambdaexecutionpolicy

{
	"AWSTemplateFormatVersion": "2010-09-09",
	"Description": "Lambda resource stack creation using Amplify CLI",
	"Parameters": {
		"GROUP": {
			"Type": "String",
			"Default": ""
		},
		"modules": {
			"Type": "String",
			"Default": "",
			"Description": "Comma-delimmited list of modules to be executed by a lambda trigger. Sent to resource as an env variable."
		},
		"resourceName": {
			"Type": "String",
			"Default": ""
		},
		"trigger": {
			"Type": "String",
			"Default": "true"
		},
		"functionName": {
			"Type": "String",
			"Default": ""
		},
		"roleName": {
			"Type": "String",
			"Default": ""
		},
		"parentResource": {
			"Type": "String",
			"Default": ""
		},
		"parentStack": {
			"Type": "String",
			"Default": ""
		},
		"env": {
			"Type": "String"
		}
	},
	"Mappings": {
		"graphQLAPIIdMap": {
			"dev": {
				"graphQLAPIId": "xxxxxx"
			},
			"prod": {
				"graphQLAPIId": "xxxxxx"
			},
		}
	},
	"Conditions": {
		"ShouldNotCreateEnvResources": {
			"Fn::Equals": [
				{
					"Ref": "env"
				},
				"NONE"
			]
		}
	},
	"Resources": {
		"LambdaFunction": {
			"Type": "AWS::Lambda::Function",
			"Metadata": {
				"aws:asset:path": "./src",
				"aws:asset:property": "Code"
			},
			"Properties": {
				"Handler": "index.handler",
				"FunctionName": {
					"Fn::If": [
						"ShouldNotCreateEnvResources",
						"BaseProjectAuthPostConfirmation",
						{
							"Fn::Join": [
								"",
								[
									"BaseProjectAuthPostConfirmation",
									"-",
									{
										"Ref": "env"
									}
								]
							]
						}
					]
				},
				"Environment": {
					"Variables": {
						"ENV": {
							"Ref": "env"
						},
						"MODULES": {
							"Ref": "modules"
						},
						"REGION": {
							"Ref": "AWS::Region"
						},
						"GROUP": {
							"Ref": "GROUP"
						},
						"USER_TABLE_NAME": {
							"Fn::Join": [
								"",
								[
									"User",
									"-",
									{
										"Fn::FindInMap": [
											"graphQLAPIIdMap",
											{
												"Ref": "env"
											},
											"graphQLAPIId"
										]
									},
									"-",
									{
										"Ref": "env"
									}
								]
							]
						}
					}
				},
				"Role": {
					"Fn::GetAtt": [
						"LambdaExecutionRole",
						"Arn"
					]
				},
				"Runtime": "nodejs10.x",
				"Timeout": "25",
				"Code": {
					"S3Bucket": "<removed>",
					"S3Key": "<removed>"
				},
				"Layers": []
			}
		},
		"LambdaExecutionRole": {
			"Type": "AWS::IAM::Role",
			"Properties": {
				"RoleName": {
					"Fn::If": [
						"ShouldNotCreateEnvResources",
						"BaseProjectAuthPostConfirmation",
						{
							"Fn::Join": [
								"",
								[
									"BaseProjectAuthPostConfirmation",
									"-",
									{
										"Ref": "env"
									}
								]
							]
						}
					]
				},
				"AssumeRolePolicyDocument": {
					"Version": "2012-10-17",
					"Statement": [
						{
							"Effect": "Allow",
							"Principal": {
								"Service": [
									"lambda.amazonaws.com"
								]
							},
							"Action": [
								"sts:AssumeRole"
							]
						}
					]
				}
			}
		},
		"lambdaexecutionpolicy": {
			"DependsOn": [
				"LambdaExecutionRole"
			],
			"Type": "AWS::IAM::Policy",
			"Properties": {
				"PolicyName": "lambda-execution-policy",
				"Roles": [
					{
						"Ref": "LambdaExecutionRole"
					}
				],
				"PolicyDocument": {
					"Version": "2012-10-17",
					"Statement": [
						{
							"Effect": "Allow",
							"Action": [
								"logs:CreateLogGroup",
								"logs:CreateLogStream",
								"logs:PutLogEvents"
							],
							"Resource": {
								"Fn::Sub": [
									"arn:aws:logs:${region}:${account}:log-group:/aws/lambda/${lambda}:log-stream:*",
									{
										"region": {
											"Ref": "AWS::Region"
										},
										"account": {
											"Ref": "AWS::AccountId"
										},
										"lambda": {
											"Ref": "LambdaFunction"
										}
									}
								]
							}
						},
						{
							"Effect": "Allow",
							"Action": [
								"dynamodb:PutItem"
							],
							"Resource": [
								{
									"Fn::Join": [
										"",
										[
											"arn:aws:dynamodb:",
											{
												"Ref": "AWS::Region"
											},
											":",
											{
												"Ref": "AWS::AccountId"
											},
											":table/",
											{
												"Fn::Join": [
													"",
													[
														"User",
														"-",
														{
															"Fn::FindInMap": [
																"graphQLAPIIdMap",
																{
																	"Ref": "env"
																},
																"graphQLAPIId"
															]
														},
														"-",
														{
															"Ref": "env"
														}
													]
												]
											}
										]
									]
								}
							]
						}
					]
				}
			}
		}
	},
	"Outputs": {
		"Name": {
			"Value": {
				"Ref": "LambdaFunction"
			}
		},
		"Arn": {
			"Value": {
				"Fn::GetAtt": [
					"LambdaFunction",
					"Arn"
				]
			}
		},
		"LambdaExecutionRole": {
			"Value": {
				"Ref": "LambdaExecutionRole"
			}
		},
		"Region": {
			"Value": {
				"Ref": "AWS::Region"
			}
		}
	}
}

sakhmedbayev · 2020-09-01T14:41:36Z

if anyone is OK with a more manual solution to this issue, you can do the following:

add additional IAM auth provider to your GraphQL API
decorate your @model with { allow: private, provider: iam } @auth directive
add the following permission to your lambda's IAM execution role:

        {
            "Action": [
                "appsync:Create*",
                "appsync:StartSchemaCreation",
                "appsync:GraphQL",
                "appsync:Get*",
                "appsync:List*",
                "appsync:Update*",
                "appsync:Delete*"
            ],
            "Resource": [
                "arn:aws:appsync:eu-central-1:2323232:apis/replace-with-yours/*"
            ],
            "Effect": "Allow"
        }

marianolc · 2020-09-01T22:39:48Z

The same issue. I appreciate the "workaround" but it seems really convoluted to implement when it should be something really common. We need to access to dynamoDB tables in the pre-jwt-token generation lambda:

<tablename>-<AppSyncID>-<env>

edoardo849 · 2020-09-04T13:04:24Z

Hey @kylekirkby ,

your solution almost worked for me but I think that the replacements are partially wrong. The one that worked for me are:

File /amplify/backend/backend-config.json -> as suggested by @kylekirkby

File /amplify/backend/lambdaTriggerPermissions/postConfirmationPermissions/template.json

{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Description": "",
  "Parameters": {
    "env": {
      "Type": "String"
    },
    "api{YOUR-API-NAME}GraphQLAPIEndpointOutput": {
      "Type": "String",
      "Default": "api{YOUR-API-NAME}Output"
    },
    "api{YOUR-API-NAME}GraphQLAPIIdOutput": {
      "Type": "String",
      "Default": "api{YOUR-API-NAME}GraphQLAPIEndpointOutput"
    },
    "function{YOUR-FUNCTION-NAME}LambdaExecutionRole": {
      "Type": "String",
      "Default": "function{YOUR-FUNCTION-NAME}LambdaExecutionRole"
    }
  },
  "Conditions": {},
  "Resources": {
    "GraphQLEndpointParam": {
      "Type": "AWS::SSM::Parameter",
      "Properties": {
        "Name": {
          "Fn::Join": [
            "",
            [
              "GraphQLEndpoint-",
              {
                "Ref": "env"
              }
            ]
          ]
        },
        "Type": "String",
        "Value": {
          "Ref": "api{YOUR-API-NAME}GraphQLAPIEndpointOutput"
        },
        "Description": "GraphQL API Endpoint for current stage"
      }
    },
    "PostConfirmationCognitoResourcesPolicy": {
      "Type": "AWS::IAM::Policy",
      "Properties": {
        "PolicyName": "post-confirmation-api-execution-policy",
        "Roles": [
          {
            "Ref": "function{YOUR-FUNCTION-NAME}LambdaExecutionRole"
          }
        ],
        "PolicyDocument": {
          "Version": "2012-10-17",
          "Statement": [
            {
              "Effect": "Allow",
              "Action": [
                "ssm:*"
              ],
              "Resource": "*"
            },
            {
              "Effect": "Allow",
              "Action": [
                "appsync:Create*",
                "appsync:StartSchemaCreation",
                "appsync:GraphQL",
                "appsync:Get*",
                "appsync:List*",
                "appsync:Update*",
                "appsync:Delete*"
              ],
              "Resource": [
                {
                  "Fn::Join": [
                    "",
                    [
                      "arn:aws:appsync:",
                      {
                        "Ref": "AWS::Region"
                      },
                      ":",
                      {
                        "Ref": "AWS::AccountId"
                      },
                      ":apis/",
                      {
                        "Ref": "api{YOUR-API-NAME}GraphQLAPIIdOutput"
                      },
                      "/*"
                    ]
                  ]
                }
              ]
            }
          ]
        }
      }
    }
  },
  "Outputs": {}
}

file /amplify/backend/lambdaTriggerPermissions/postConfirmationPermissions/template.json

{
  "api{YOUR-API-NAME}GraphQLAPIEndpointOutput": {
    "Fn::GetAtt": [
      "{YOUR-API-NAME}",
      "Outputs.GraphQLAPIEndpointOutput"
    ]
  },
  "api{YOUR-API-NAME}GraphQLAPIIdOutput": {
    "Fn::GetAtt": [
      "{YOUR-API-NAME}",
      "Outputs.GraphQLAPIIdOutput"
    ]
  },
  "function{YOUR-FUNCTION-NAME}LambdaExecutionRole": {
    "Fn::GetAtt": [
      "function{YOUR-FUNCTION-NAME}",
      "Outputs.LambdaExecutionRole"
    ]
  }
}

slatemates · 2020-09-11T19:01:16Z

Thanks @paulsson @kylekirkby .The solution works perfectly. However is there a way to call a graphql end point using a seperate lambda (due to 5 sec constraint ) using a custom SQS deployment and triggering the lambda .

bart · 2020-09-25T14:05:26Z

After putting some effort into this issue I also got faced with I came up with the following solution.

I had the exact same use case as @MontoyaAndres: A circular dependency issue caused by a post confirmation function that needs API access (at least to get the GraphQL ID). After diving into this problem and reading tons of solutions and explanations, especially by @paulsson and @kylekirkby I came up with an own, in my opinion even simpler solution. I used the custom resource stack (amplify/backend/api/{your-api-name}/stacks/CustomResources.json) and exported the AppSyncApiId INSTEAD of doing an amplify function update.

[...]
"Outputs": {
    [...]
    "StaticGraphQLAPIId": {
      "Description": "GraphQL API ID with static export name",
      "Value": {
        "Ref": "AppSyncApiId"
      },
      "Export": {
        "Name": {
          "Fn::Join": [
            ":",
            [
              {
                "Fn::Join": [
                  "",
                  [
                    "api",
                    {
                      "Ref": "AppSyncApiName"
                    }
                  ]
                ]
              },
              {
                "Ref": "env"
              },
              "StaticGraphQLApiId"
            ]
          ]
        }
      }
    }
  }

Now I can use this exported value (which contains the dynamic part of all DynamoDB tables) to access DynamoDB from my Lambda function directly importing this value like this:

// amplify/backend/function/{your-post-confirmation-function}/parameters.json

{
  [...]
  "AppSyncApiName": "{your-api-name}"
{

// amplify/backend/function/{your-post-confirmation-function}/{your-post-confirmation-function}-cloudformation-template.json

"Parameters": {
    [...]
    "AppSyncApiName": {
      "Type": "String",
      "Description": "The name of the AppSync API",
      "Default": ""
    }
},

[...]
"Resources": {
  [...]
  "Properties": {
    [...]
    "Environment": {
      "Variables": {
        [...]
        "GRAPHQLID": {
              "Fn::ImportValue": {
                "Fn::Join": [
                  ":",
                  [
                    {
                      "Fn::Join": [
                        "",
                        [
                          "api",
                          {
                            "Ref": "AppSyncApiName"
                          }
                        ]
                      ]
                    },
                    {
                      "Ref": "env"
                    },
                    "StaticGraphQLApiId"
                  ]
                ]
              }
            }

You now have access to process.env.GRAPHQLID from your NodeJS Lambda function and can execute DynamoDB actions according to your personal use case. For DynamoDB access you might extend your post confirmation function resource by corresponding resource policy (also in {your-post-confirmation-function}-cloudformation-template.json).

Hope it helps so that you don't have to spend hours and hours of research. Solving this circular dependency issue in amplify-cli would be appreciated.

morgler · 2020-10-28T12:43:30Z

It amazes me, that in so many common use cases for Amplify you need to circumvent Amplify and hack it yourself. I like the idea of Amplify, but being told these workarounds to dive into generated files you should rarely see (let alone edit) feels bad. At least these kinds of workarounds should not be necessary on your first tutorial implementing basic functionality. It would be great to see this handled by Amplify.

Btw: For me this problem is actually yak shaving for another basic functionality: syncing your Cognito users with the users in your AppSync. If that first thing would be included in Amplify, I wouldn't even need the Lambda permission to access AppSync in the trigger.

bart · 2020-10-28T13:57:08Z

@morgler Absolutely. And beside of that authentication rules are not flexible enough. Simple use cases like showing all properties to some groups but exclude some for public access isn't possible in combination with connections. That's why we decided to build a good old fashioned REST API microservice architecture using serverless framework instead of Amplify Backend.

morgler · 2020-10-28T17:25:15Z

@bart I also use serverless in production - it's more mature and flexible.

However I haven't completely given up on Amplify over the past years. I still hope this develops into a mature tool that makes micro services even more convenient than serverless. My feeling is, that while two years ago I couldn't use Amplify for anything, today I can at least work around the missing pieces using serverless. I will keep playing with Amplify, but will likely rely on serverless in production for quite some time.

xitanggg · 2020-11-12T11:55:22Z

I initially plan to use a Post Confirmation Lambda to call AppSync and auto-create a user profile for each user at the database upon a successful confirm sign up. After reading this thread, it sounds like such a hassle to work around it in Post Confirmation Lambda due to circular dependency.

I realize I am better off letting users to call AppSync directly and create their own profile in the client side when they first login. To me, it is easier to set up a custom createProfile resolver in vtl for user to call.

For people experiencing similar issue with post confirmation lambda, I think it is possible to re-consider your use case. And if it can be moved to client side with a custom resolver, it can be an easier alternative to consider.

Cheers

hisham · 2020-12-02T23:22:39Z

@bart your solution did not work for me as. I got "No export named api::StaticGraphQLApiId found". Don't you need to add a dependsOn on the lambda since it now depends on the graphql api outputs? But wouldn't this re-introduce the circular issue? I think your solution would work if I do the deploy in two phases (one to export the output, the other to add the lambda), but it didn't work for me in one step.

bart · 2020-12-03T01:55:18Z

@hisham Maybe you did something different. I didn't add the dependency because as you said it would re-introduce this circular dependency problem. And I also didn't deploy in two phases. Just did it as described.

ayeganyan · 2020-12-04T14:53:10Z

I have added dependency to storage->tablename to post-confirmation lambda to save user data, but also have the same issue.
I confused, does dynamodb has dependency on Cognito?

vitalbone · 2020-12-08T17:35:11Z

Update:
(09/12/2020)
This is still not working. The bug was obscured by a vague error log that only helps compound the issue, rather than fix it. Classic Amplify. Apologies to all that may have gotten their hopes up 😅

(08/12/2020)
I ran into this issue recently. I have since updated the cli tool globally and the issue seems to be fixed. YMMV!

Steps:

yarn global add @aws-amplify/cli aws-amplify/amplify-cli#4.38.0
amplify push --yes

iyz91 · 2020-12-11T17:24:47Z

Yet another workaround is to simply not register any trigger when configuring your auth and just set them in the AWS Console afterwards (or through the AWS CLI).

While this goes outside of the Amplify CLI and is not IaC, it's arguably the easiest and quickest option, least prone to errors, maintains dynamic env vars, and involves a quick manual step on the likely least changing part of your stack. This works as far as I can tell, at least for those using an API with Cognito Auth + Cognito triggers that use API/Dynamo access.

Relevant Steps From Scratch:

Configure auth, be sure to not set any triggers
Create your intended trigger functions, and provide any api/storage access you require through the CLI
Configure everything else as normal (e.g. API with Cognito User Pool auth)
Go to Cognito in AWS Console and set the relevant trigger lambdas (or through the AWS CLI)

Steps for those already suffering with cyclic dependency issue:

Delete any and all references to Cognito triggers in the various files
- backend/backend-config.json: Delete relevant references in "dependsOn" property
- backend/auth/{AuthName}/parameters.json:
  - Delete relevant references in "dependsOn" property
  - Reset "triggers" property to a blank string
- backend/auth/{AuthName}/{AuthName}-cloudformation-template.yml:
  - Delete trigger function Arns & Names (e.g. function{FunctionName}Arn/Name)
  - Delete trigger invoke permissions (e.g. UserPoolPostConfirmationLambdaInvokePermission)
  - Delete whole LambdaConfig under UserPool in Resources section
Perform Steps from Scratch if you haven't already done so

You may ask why all the trouble for the second set of steps? I'm not able to remove a single remaining trigger, hence the manual edits. See #5986

Note to the CLI team: You guys have done an amazing job and I'm sure addressing these problems is quite complex. Nevertheless, if you can fix issues like this, the one I linked to above, being able to add lambda environment vars from the CLI and other common things like that, I'd be much more inclined to recommend Amplify to others. It seems like the vast majority of work for a lot of use cases is done, it's just last mile nitty gritty work. Thanks for all your efforts.

ayeganyan · 2020-12-12T20:13:32Z

As a workaround, I set up custom SQS resource and add dependency/permission to post on it from postcomfrirmation function, finally added another trigger from SQS which writes to DynamoDB.
A little bit long way but works !

waltermvp · 2020-12-14T18:47:30Z

@ayeganyan can you post how you set it up?

ayeganyan · 2020-12-15T05:53:50Z

Hi @waltermvp

Create SQS in queue category:
amplify/backend/queue/postConfirmationQueue-cloudformation-template.json

{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Description": "Queue resource stack creation using Amplify CLI",
  "Parameters": {
    "env": {
      "Type": "String"
    }
  },
  "Conditions": {
    "ShouldNotCreateEnvResources": {
      "Fn::Equals": [
        {
          "Ref": "env"
        },
        "NONE"
      ]
    }
  },
  "Resources": {
    "SQS": {
      "Type": "AWS::SQS::Queue",
      "Properties": {
        "QueueName": {
          "Fn::If": [
            "ShouldNotCreateEnvResources",
            "postConfirmationEvent",
            {
              "Fn::Join": [
                "",
                [
                  "postConfirmationEvent",
                  "-",
                  {
                    "Ref": "env"
                  }
                ]
              ]
            }
          ]
        }
      }
    }
  },
  "Outputs": {
    "Name": {
      "Value": {
        "Ref": "SQS"
      }
    },
    "Arn": {
      "Value": {
        "Fn::GetAtt": ["SQS", "Arn"]
      }
    },
    "Region": {
      "Value": {
        "Ref": "AWS::Region"
      }
    }
  }
}

Add the new resource and dependencies on it in amlify/backend/backend-config.json

  "queue": {
    "postConfirmationQueue": {
      "service": "SQS",
      "providerPlugin": "awscloudformation"
    }
  },
...
 "authenticationPostConfirmation": {
      "build": true,
      "providerPlugin": "awscloudformation",
      "service": "Lambda",
      "dependsOn": [
        {
          "category": "queue",
          "resourceName": "postConfirmationQueue",
          "attributes": [
            "Name"
          ]
        }
      ]
    },
 "postConfirmationQueueTrigger": {
      "build": true,
      "providerPlugin": "awscloudformation",
      "service": "Lambda"
}

Add permission settings and SQS inputs for postConfirmation function in amplify/backend/function/authenticationPostConfirmation/authenticationPostConfirmation-cloudformation-template.json:

{
Parameters:
...
    "queuepostConfirmationQueueName": {
      "Type": "String"
      "Description": "Should be in <category><resource><output> format"
    },
    "queuepostConfirmationQueueArn": {
      "Type": "String"
    },
....
   "Environment": {
     ....
            "SQS_POSTCONFIRMATION_QUEUE": {
              "Ref": "queuepostConfirmationQueueName"
            },
    }
...
...
    "AmplifyResourcesPolicy": {
      "DependsOn": [
        "LambdaExecutionRole"
      ],
      "Type": "AWS::IAM::Policy",
      "Properties": {
        "PolicyName": "amplify-lambda-execution-policy",
        "Roles": [
          {
            "Ref": "LambdaExecutionRole"
          }
        ],
        "PolicyDocument": {
          "Version": "2012-10-17",
          "Statement": [
            {
              "Effect": "Allow",
              "Action": [
                "sqs:SendMessage",
                "sqs:GetQueueAttributes"
              ],
              "Resource": [
                {
                  "Fn::Sub": "${queuepostConfirmationQueueArn}"
                }
              ]
            }
          ]
        }
      }
    }

Pass SQS ARN and name as input in amplify/backend/function/authenticationPostConfirmation/parameters.json:

{
  "modules": "custom",
  "resourceName": "authenticationPostConfirmation",
  "queuepostConfirmationQueueArn": {
    "Fn::GetAtt": ["queuepostConfirmationQueue", "Outputs.Arn"]
  },
  "queuepostConfirmationQueueName": {
    "Fn::GetAtt": ["queuepostConfirmationQueue", "Outputs.Name"]
  }
}

Create function and add event source mapping to trigger on SQS events, pass queuepostConfirmationQueueArn and queuepostConfirmationQueueName in the same way as above: amplify/backend/function/postConfirmationQueueTrigger/postConfirmationQueueTrigger-cloudformation-template.json

  "Resources": {
    "LambdaFunction": {
...
  },
    "LambdaEventSourceMappingPostConfirmationQueue": {
      "Type": "AWS::Lambda::EventSourceMapping",
      "DependsOn": [
        "AmplifyResourcesPolicy",
        "LambdaExecutionRole"
      ],
      "Properties": {
        "BatchSize": 10,
        "MaximumBatchingWindowInSeconds": 5,
        "Enabled": true,
        "EventSourceArn": {
          "Fn::Sub": "${queuepostConfirmationQueueArn}"
        },
        "FunctionName": {
          "Fn::GetAtt": [
            "LambdaFunction",
            "Arn"
          ]
        }
      }
    },
...
    "AmplifyResourcesPolicy": {
      "DependsOn": [
        "LambdaExecutionRole"
      ],
      "Type": "AWS::IAM::Policy",
      "Properties": {
        "PolicyName": "amplify-lambda-execution-policy",
        "Roles": [
          {
            "Ref": "LambdaExecutionRole"
          }
        ],
        "PolicyDocument": {
          "Version": "2012-10-17",
          "Statement": [
            {
              "Effect": "Allow",
              "Action": [
                "sqs:ReceiveMessage",
                "sqs:DeleteMessage",
                "sqs:GetQueueAttributes"
              ],
              "Resource": [
                {
                  "Fn::Sub": "${queuepostConfirmationQueueArn}"
                }
              ]
            },
....

Send to SQS in the function and receive in another function!

  const params = {
    MessageBody: item,
    QueueUrl: process.env.SQS_POSTCONFIRMATION_QUEUE,
  }
  const res = await sqs
    .sendMessage(params)
    .promise()

Hope this will help!

ayeganyan · 2020-12-16T06:57:09Z

@waltermvp the functionality is broken in latest version (at least 4.39.0)
4.29.8 is working fine

mansdahlstrom1 · 2021-01-12T16:10:29Z

After putting some effort into this issue I also got faced with I came up with the following solution.

I had the exact same use case as @MontoyaAndres: A circular dependency issue caused by a post confirmation function that needs API access (at least to get the GraphQL ID). After diving into this problem and reading tons of solutions and explanations, especially by @paulsson and @kylekirkby I came up with an own, in my opinion even simpler solution. I used the custom resource stack (amplify/backend/api/{your-api-name}/stacks/CustomResources.json) and exported the AppSyncApiId INSTEAD of doing an amplify function update.
[...]
"Outputs": {
    [...]
    "StaticGraphQLAPIId": {
      "Description": "GraphQL API ID with static export name",
      "Value": {
        "Ref": "AppSyncApiId"
      },
      "Export": {
        "Name": {
          "Fn::Join": [
            ":",
            [
              {
                "Fn::Join": [
                  "",
                  [
                    "api",
                    {
                      "Ref": "AppSyncApiName"
                    }
                  ]
                ]
              },
              {
                "Ref": "env"
              },
              "StaticGraphQLApiId"
            ]
          ]
        }
      }
    }
  }
Now I can use this exported value (which contains the dynamic part of all DynamoDB tables) to access DynamoDB from my Lambda function directly importing this value like this:
// amplify/backend/function/{your-post-confirmation-function}/parameters.json

{
  [...]
  "AppSyncApiName": "{your-api-name}"
{

// amplify/backend/function/{your-post-confirmation-function}/{your-post-confirmation-function}-cloudformation-template.json

"Parameters": {
    [...]
    "AppSyncApiName": {
      "Type": "String",
      "Description": "The name of the AppSync API",
      "Default": ""
    }
},

[...]
"Resources": {
  [...]
  "Properties": {
    [...]
    "Environment": {
      "Variables": {
        [...]
        "GRAPHQLID": {
              "Fn::ImportValue": {
                "Fn::Join": [
                  ":",
                  [
                    {
                      "Fn::Join": [
                        "",
                        [
                          "api",
                          {
                            "Ref": "AppSyncApiName"
                          }
                        ]
                      ]
                    },
                    {
                      "Ref": "env"
                    },
                    "StaticGraphQLApiId"
                  ]
                ]
              }
            }
You now have access to process.env.GRAPHQLID from your NodeJS Lambda function and can execute DynamoDB actions according to your personal use case. For DynamoDB access you might extend your post confirmation function resource by corresponding resource policy (also in {your-post-confirmation-function}-cloudformation-template.json).

Hope it helps so that you don't have to spend hours and hours of research. Solving this circular dependency issue in amplify-cli would be appreciated.

Just a Follow up on @bart Answer, i have the same use case and solved it with the help of his instructions.

To give your lambda access to DynamoDB you can add the following cloudformation snippet to amplify/backend/function/{your-post-confirmation-function}/{your-post-confirmation-function}-cloudformation-template.json

{
  "Resources": {
    { ... },
    "lambdaexecutionpolicy": {
      { ... }
      "Properties": {
        { ... }
        "PolicyDocument": {
          "Version": "2012-10-17",
          "Statement": [
            { ... }
            {
              "Effect": "Allow",
              "Action": [
                "dynamodb:BatchGet*",
                "dynamodb:DescribeStream",
                "dynamodb:DescribeTable",
                "dynamodb:Get*",
                "dynamodb:Query",
                "dynamodb:Scan",
                "dynamodb:BatchWrite*",
                "dynamodb:CreateTable",
                "dynamodb:Delete*",
                "dynamodb:Update*",
                "dynamodb:PutItem"
              ],
              "Resource": "*"
            }
          ]
        }
      }
    }
  }
}

Please not that you can also change "Resource" to only allow access to a specific table, see more here: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_dynamodb_specific-table.html

Also you can remove / edit allowed Action to fit your use case!

attilah · 2021-01-12T17:14:11Z

Closing in favor of: #4568

github-actions · 2021-05-25T08:05:35Z

This issue has been automatically locked since there hasn't been any recent activity after it was closed. Please open a new issue for related bugs.

Looking for a help forum? We recommend joining the Amplify Community Discord server *-help channels for those types of questions.

UnleashedMind added functions Issues tied to the functions category pending-triage Issue is pending triage labels Jul 23, 2019

UnleashedMind assigned kaustavghosh06 Jul 29, 2019

kaustavghosh06 added bug Something isn't working and removed pending-triage Issue is pending triage labels Aug 22, 2019

kaustavghosh06 mentioned this issue Aug 22, 2019

Circular dependency between resources: [functionauthPreSignup, apiapi, authauth, UpdateRolesWithIDPFunctionOutputs, UpdateRolesWithIDPFunction] #2076

Closed

oste mentioned this issue Aug 26, 2019

No way to set Pre-Token trigger function for Cognito through Amplify / Cloudformation #1844

Closed

thedgbrt mentioned this issue Sep 18, 2019

Cannot give postConfirmation trigger access to auth #2303

Closed

BabyDino mentioned this issue Nov 11, 2019

How Do I get UserPoolId, GraphQLAPIIdOutput, GraphQLAPIEndpointOutput in PostConfirmation Function #2699

Closed

fomson mentioned this issue Nov 4, 2020

Trying to use model within post-confirmation function #4568

Closed

xitanggg mentioned this issue Nov 12, 2020

'amplify function update' fails to remove API dependency for post confirmation lambda triggers #5845

Closed

attilah mentioned this issue Jan 12, 2021

Auth Trigger Function environment variables not configured correctly #6361

Closed

attilah closed this as completed Jan 12, 2021

akshbhu mentioned this issue Feb 9, 2021

Access GraphQL API from Cognito Triggers #6413

Closed

github-actions bot locked as resolved and limited conversation to collaborators May 25, 2021

Get apiaivyGraphQLAPIIdOutput in auto generated PostConfirmation Lambda? #1874

Get apiaivyGraphQLAPIIdOutput in auto generated PostConfirmation Lambda? #1874

Comments

davidbiller commented Jul 20, 2019

haverchuck commented Jul 21, 2019

davidbiller commented Jul 21, 2019

ErickTamayo commented Jul 22, 2019 • edited Loading

voidarg commented Jul 23, 2019 • edited Loading

gchablowski commented Aug 8, 2019 • edited Loading

DanNeish commented Aug 14, 2019

rpostulart commented Oct 16, 2019 • edited Loading

wellini commented Oct 21, 2019

rfpedrosa commented Nov 6, 2019

patspam commented Nov 9, 2019

BabyDino commented Nov 11, 2019

rahulvyas1 commented Nov 15, 2019 • edited Loading

gretchen-blackwood commented Nov 26, 2019

davidbiller commented Nov 26, 2019

grigull commented Dec 18, 2019

paulsson commented Jan 16, 2020

amuresia commented Jan 17, 2020

dtelaroli commented Jan 20, 2020

mdebo commented Jan 21, 2020

martinjuhasz commented Jan 29, 2020

dylan-westbury commented Aug 31, 2020 • edited Loading

sakhmedbayev commented Sep 1, 2020 • edited Loading

marianolc commented Sep 1, 2020

edoardo849 commented Sep 4, 2020 • edited Loading

slatemates commented Sep 11, 2020

bart commented Sep 25, 2020 • edited Loading

morgler commented Oct 28, 2020

bart commented Oct 28, 2020

morgler commented Oct 28, 2020 • edited Loading

xitanggg commented Nov 12, 2020

hisham commented Dec 2, 2020

bart commented Dec 3, 2020

ayeganyan commented Dec 4, 2020

vitalbone commented Dec 8, 2020 • edited Loading

iyz91 commented Dec 11, 2020

ayeganyan commented Dec 12, 2020 • edited Loading

waltermvp commented Dec 14, 2020

ayeganyan commented Dec 15, 2020

ayeganyan commented Dec 16, 2020

mansdahlstrom1 commented Jan 12, 2021

attilah commented Jan 12, 2021

github-actions bot commented May 25, 2021

ErickTamayo commented Jul 22, 2019 •

edited

Loading

voidarg commented Jul 23, 2019 •

edited

Loading

gchablowski commented Aug 8, 2019 •

edited

Loading

rpostulart commented Oct 16, 2019 •

edited

Loading

rahulvyas1 commented Nov 15, 2019 •

edited

Loading

dylan-westbury commented Aug 31, 2020 •

edited

Loading

sakhmedbayev commented Sep 1, 2020 •

edited

Loading

edoardo849 commented Sep 4, 2020 •

edited

Loading

bart commented Sep 25, 2020 •

edited

Loading

morgler commented Oct 28, 2020 •

edited

Loading

vitalbone commented Dec 8, 2020 •

edited

Loading

ayeganyan commented Dec 12, 2020 •

edited

Loading