Scale up lambda failing - options.appID and options.privateKey are not set

[Brandoffsky]

Hey folks! I am wondering if anyone else has come across an issue where the scale up lambda fails due to octokit/auth-app not being able to retrieve the appID and privateKey from the options variable in the scale-up lambda. I've attempted a couple of different deploys at this point and still get the same result. I have also verified that SMM does indeed have the parameters stored. I am using v.0.27.2.

Thanks in advance for any suggestions!
-B.

[npalm]

No I don't recognize the error. The lambda is retrieving has 2 environment variables that points to parameters in SSM which should contain the app id and the ssh key. Would suggest that you check those.

[Brandoffsky]

Thanks! I was able to get past the issue by hardcoding those 2 variables in the lambda rather than have them fetched in SSM. Permissions looked correct and the data was indeed in SSM. The path initially in the ENV variable value that pointed to SSM also looked correct. Im now trying to debug the next error down the chain with receiving a 400. It looks to be another parameter issue, but I am still attempting to figure out from where.

[Brandoffsky]

Me again!

I am still running in to the same issue as posted above. The root cause seems to all stem from getting parameters from SSM. Ive gone through with one of my colleagues and tried the following:

• Hardcode the appID and base_64 variables on the Lambda (as noted in my previous post)
• Update to a later release
• Update execution role on the Lambda to be 'Admin" in an attempt to root out a permissions issue
• Verified values in parameter store are correct and accessible through CLI commands (aws ssm get-parameter --name /actions_runner/beamable-git-runners/github_app_key_base64)
• Attempted to add KMS support using both a user generated and AWS managed key
• Fully destroyed and re-applied the environment after version updates
• Check cloud trail to make sure the Lambda role was being assumed

Regardless of what has been attempted, I still end up back with the [@octokit/auth-app] appId option is required error, though it is now ignored (log formatting is much nicer than previous versions, ty!). Any other thoughts? TIA!

[ScottGuymer]

This seems like it could be a permissions issue as we have not seen this kind of issue across various accounts and deployments.

You could check to see if some permission boundaries or other restrictions have been placed on the account at a higher level. These may prevent you from granting access to resources even if you have successfully created the policies and applied them.

Did you try any of the tools in the console to check effective permissions?