-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(lambda): failed to add permission to an imported lambda from another account #11369
Conversation
…her account Originally, when a function was imported into an account agnostic stack, it was assumed that the function was from a different account and hence its permission cannot be modified. A subsequent change - 99111f7 - changed this behaviour to its opposite. When an account agnostic stack was encountered in the context of an imported function, it was assumed that the function was part of the same account. This has caused customers to report regressions - #11278, #11141. This change reverts this behaviour back to its original assumption, with the additional ability to configure this explicitly by the user if needed for an advanced use case. fixes #11141
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like the error message in grantInvoke
should be updated to reflect this, as we're going to break (other) existing customers with this revert.
Also wouldn't mind a second set of eyes here.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Originally, when a function was imported into an account agnostic stack,
it was assumed that the function was from a different account and hence
its permission cannot be modified.
A subsequent change - 99111f7 - changed
this behaviour to its opposite. When an account agnostic stack was
encountered in the context of an imported function, it was assumed that
the function was part of the same account.
This has caused customers to report regressions - #11278, #11141.
This change reverts this behaviour back to its original assumption, with
the additional ability to configure this explicitly by the user if
needed for an advanced use case.
fixes #11141
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license