Aws-sdk-js: The role defined for the function cannot be assumed by Lambda.

Created on 16 Oct 2020  Â·  9Comments  Â·  Source: aws/aws-sdk-js

Confirm by changing [ ] to [x] below:

Describe the question
I have a issue/problem and was wondering what is the best practice? I get the following error when I try to create a Lambda function about 30% of the time using the nodejs sdk:

The role defined for the function cannot be assumed by Lambda.

I have a sequence of async calls to create a role, attach policy and create a function ... the problem is
how to wait for the role/policy to be ready? Using async/await/promise doesn't work about 30% of time. If you list the attached policies on the role, it shows a policy attached even though you can't create the function yet. I even experimented with using AWS.request events ... I'm try to avoid looping until it works ... Any thoughts?

guidance

Most helpful comment

This isn't really a problem with the AWS SDK but rather that the AWS APIs themselves are "eventually consistent" and it is expected that changes won't be reflected immediately.

There is some documentation about this here and a relevant forum post here that has more info.

All 9 comments

I think you just have to sleep or retry. Terraform handles exactly this scenario with a retry.

https://github.com/terraform-providers/terraform-provider-aws/blob/943230985fefc7b203eedaf6059e905279b27645/aws/resource_aws_lambda_function.go#L333-L353

@philipwigg thanks for providing that, @bbarthel will be closing this issue, please reach out if you have any other questions.

Please reconsider reopening this issue and provide specific guidance on how one should coordinate dependent sequential sdk calls. If polling is really the answer, what are intervals and for how long? I understand that this is a difficult problem but, it really needs to have a better solution. How do SAM or cdk internally handle this problem?

This isn't really a problem with the AWS SDK but rather that the AWS APIs themselves are "eventually consistent" and it is expected that changes won't be reflected immediately.

There is some documentation about this here and a relevant forum post here that has more info.

@philipwigg I agree that its not a problem with the SDK per se but, practical guidance on how to work with services that are "eventually consistent" would be helpful ... another angle would be to create new events that fires when the action is "consistent" or "mostly consistent"? Maybe someway to provide better visibility in what it means to being "consistent"

Yep, I see your point but I'm not sure such guidance exists (or will ever be provider) other than the "eventual consistency" links I sent earlier (I don't work for Amazon so I could be wrong here!).

Basically you have to poll to see if your resource is in the right state (or in your case, if the lambda can assume the role), if it can't then wait a few seconds and retry. I would probably wait about 5 or 10 seconds between checks and give up after a few minutes.

You can see how Terraform handles this with an exponential backoff here.

Thanks @philipwigg! I like the exponential backoff ... in my limited testing, the process eithers works pretty quickly or not ...

It was closed because as @philipwigg pointed this not an AWS-SDK issue and is it is also documented in the documentation provided before I believe it should not be reopened, I can mark this as a cross SDK feature but as this is already addressed in the documentation, I believe it wont be prioritized as it doesn't really resolves any bugs.

Let me know what you think about it @bbarthel

@ajredniwja I will try another approach and make a feature request. The SDK already has Waiter Resource States for userExists, roleExists and policyExists. I recommend the SDK should have a new one like 'policyIsAttached'. This would be for the function eg

iam.waitFor('policyIsAttached', params = {}, [callback]) ⇒ AWS.Request

Was this page helpful?
0 / 5 - 0 ratings