(codepipeline): Error: The 'account' property must be a concrete value

[Nemanjalj66]

What is the problem?

After updating Amazon.CDK.Lib from 2.3.0 to 2.12.0 the LambdaInvokeAction fails to synthesize.

Reproduction Steps

Run CDK synth of the following code:

var changeVersionLambda = Function.FromFunctionArn(this, "changeVersionLambda", changeVersionLambdaArn);

new Amazon.CDK.AWS.CodePipeline.StageProps
{
      StageName = "Deploy_Test",
      Actions = new IAction[]
      {
          new LambdaInvokeAction(new LambdaInvokeActionProps() {
              ActionName = "Populate_Parameters",
              Lambda = changeVersionLambda,
              UserParameters = new Dictionary<string, object>
              {
                  ["component"] = "service",
                  ["environment"] = PlatformEnvironment.Test.ToString(),
                  ["version"] = nodeServiceBuildAction.Variable("NEW_VERSION")
              }
          })
      }
}

What did you expect to happen?

CDK synth executes successfully.

What actually happened?

CDK synth fails.

Exception: Amazon.JSII.Runtime.JsiiException: The 'account' property must be a concrete value (action: 'Populate_Version_Parameters')

CDK CLI Version

2.12.0

Framework Version

No response

Node.js Version

v14.17.0

OS

Windows

Language

.NET

Language Version

No response

Other information

No response

[skinny85]

Hey @Nemanjalj66,

thanks for opening the issue. I assume this is because #18255 was one of the changes that got merged between 2.3.0 and 2.12.0.

Is your pipeline in the same account as the Function you're importing with Function.FromFunctionArn()?

[github-actions]

This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

[Nemanjalj66]

Hey @skinny85,

thanks for the response.

Yes, it is in the same account.

[skinny85]

OK, that's good. That means you should be able to unblock yourself by specifying the account (and probably region) of the pipeline Stack to the same values as are present in the Lambda function's ARN.

However, long-term, I think we should introduce a Function.fromFunctionName() method that allows you to skip all of this dance, and just always assumes the Function is in the same account and region you are importing it to.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[Nemanjalj66]

OK, that's good. That means you should be able to unblock yourself by specifying the account (and probably region) of the pipeline Stack to the same values as are present in the Lambda function's ARN.

However, long-term, I think we should introduce a Function.fromFunctionName() method that allows you to skip all of this dance, and just always assumes the Function is in the same account and region you are importing it to.

The account and region that are present in the lambda ARN are already explicitly stated in the Environment property of the pipeline stack. That was already done when I opened the issue.
Do you have any ideas why this doesn't work?

[skinny85]

Can you show what is changeVersionLambdaArn in your code?

[Nemanjalj66]

Here's the definition:
var changeVersionLambdaArn = StringParameter.FromStringParameterName(this, "changeVersionLambdaArn", "change-deployed-component-version-function-arn").StringValue;

Here's the value:
"arn:aws:lambda:eu-central-1:XXXXXXXXXXXX:function:ChangeComponentDeployedVe-ChangeComponentDeployedV-sLDFu663Ook"

Here' the pipeline stack instantiation:

new PipelineStack(app, "PipelineStack", new StackProps() { Env = new Environment() { Region = "eu-central-1", Account = XXXXXXXXXXXX}, });

Account id from the ARN and the pipeline stack are matching.

[skinny85]

Yes, so I see the problem. The ARN of the Function is a dynamic (deploy-time only) value. Because of that, the CDK cannot figure out whether the Function and the Pipeline are in the same account/region, or not.

You said:

Account id from the ARN and the pipeline stack are matching.

Is there any chance you can remove that explicit env property from the pipeline Stack, and see if that helps?

Thanks,
Adam

[Nemanjalj66]

Thank you for the answer. Creating an environment-agnostic pipeline stack did help. However, this may cause a problem when this kind of stack is not appropriate.

If StringParameter.FromStringParameterName causes the problem, then the alternative maybe should be
StringParameter.ValueFromLookup (this should provide the value at synth time)?
I tried this approach but I encountered the following issue: #8699

Adding "fromFunctionName" method should solve all of these issues?

Edit: One potential workaround for the ARN issue is to store only the Lambda function name in the Parameter store (this enables getting the information in the compile-time) and create the ARN from the environment data (account, region) from the Pipeline stack.

[skinny85]

Yes, the fromFunctionName() was created specifically for solving this problem.

Edit: One potential workaround for the ARN issue is to store only the Lambda function name in the Parameter store (this enables getting the information in the compile-time) and create the ARN from the environment data (account, region) from the Pipeline stack.

Absolutely, this workaround would work too.

If StringParameter.FromStringParameterName causes the problem, then the alternative maybe should be StringParameter.ValueFromLookup (this should provide the value at synth time)? I tried this approach but I encountered the following issue: #8699

Yes, that should work. Sorry for encountering some many obstacles here 😕.

Hopefully, your workaround with formatting the ARN "manually" from above should unblock you until we release a version with the fromFunctionName(), where you'll be able to use that directly, without worrying about the ARN.

Apologies for the bad experience!

[Nemanjalj66]

OK, thank you for your help!

[skinny85]

Of course! And apologies again for the bad experience.

I'm going to close this one, please comment if you need anything else form our side for this issue.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.