chore(scheduler-targets-alpha): imported function as a LambdaInvoke target results in synth-time error

[anan-k]

Issue # (if applicable)

Closes #29284

Reason for this change

When a lambda function in another stack is imported by ARN and used as a LambdaInvoke target, a synth-time error occurred due to an issue with environment (account or region) validation sameEnvDimension. The validation compares two environment values such as account or region and returns true/false. The validation passes only if the values are the same (SAME) or both are unresolved (BOTH_UNRESOLVED), but since the region of the imported function was unresolved, it resulted in ONE_UNRESOLVED, causing the error. To resolve this, I modified the validation to allow the ONE_UNRESOLVED case.

The proposed solution in the issue was to skip validations if sameEnvironment is set to true on the imported lambda. However, I did not adopt this solution because the sameEnvironment attribute is not stored in the Lambda function itself and cannot be used to toggle the validation.

Description of changes

I changed the sameEnvDimension function to allow the case where either one of the parameters is unresolved.
I made these changes based on the implementation in aws-cdk-lib/aws-events-targets/lib/util.ts

Description of how you validated changes

I added a unit test for the LambdaInvoke target to cover the case when an imported lambda function is used.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

[anan-k]

Exemption Request: This PR just changes validation behavior and does not affect the integration test. The changes are covered by unit tests.

[aaythapa]

Hi, thank you for your contribution! Did a quick review and I'm not sure if this is the best way to fix this, see comment.

The proposed solution in the issue was to skip validations if sameEnvironment is set to true on the imported lambda. However, I did not adopt this solution because the sameEnvironment attribute is not stored in the Lambda function itself and cannot be used to toggle the validation.

Agree, that doesn't work for now. Will do a deeper dive to see if there is a way to expose this property

[aaythapa]

Correct me if I'm wrong but this essentially negates the need for the validation as, I believe now, all cases will return true.

EDIT: I see that TokenComparison.DIFFERENT can also be returned which would return false for this function. I'm still not sure if this is the best way to go about resolving this issue as it could change more things than just fixing this issue. Will consult with the team

[anan-k]

See comment: #29615 (comment)

[anan-k]

Hi Aayush, thank you for your review and comment. Let me check it.

[anan-k]

@aaythapa
I'm sorry for the late reply and thank you again for your comment.

As you mentioned, this change is more of a fundamental solution to just resolve this issue rather than a minimum change. However, the proposed addition of the sameEnvironment property to Lambda is considered to have an even greater impact. Furthermore, due to the nature of the property, it may not be appropriate for Lambda to retain it.

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 0da03df
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[anan-k]

@aaythapa
Hi Aayush, I would appreciate it if you check the comment above:

#29615 (comment)

[TheRealAmazonKendra]

TBH, I'm not sure I even feel this validation is worth while or that it should have been added to events targets. I probably would have turned down that PR when it initially came in if I had been the reviewer.

I'm curious what the user experience for this failure is if the environments aren't the same. Is the failure clear? Is it a fast failure at deploy time? If so, I'd prefer to delete this altogether. If not, your change is probably fine but we do need to have the conflicts resolved prior to being able to accept this so I'm putting it in changes requested for either path.

[paulhcsun]

Hi @anan-k, just pinging on this PR again to see if you're still interested in working on it. There's just the merge conflicts and comment by Kendra to be addressed.

[anan-k]

Hi @paulhcsun, thank you for pinging to me. Thank you @TheRealAmazonKendra for the comment. Based on the comments received, I will reconsider the impact on users when validation fails and the methods for correction.
However, please understand that the start of this work will be in two weeks.

[samson-keung]

I agree with @TheRealAmazonKendra that this validation is not worth while, even though it was good intention to let the customer know early that target in a different environment is not supported. Reasons:

1. At synth time, there are cases where CDK does not know about the actual environment (e.g. when the environment is using Tokens). In other words, the environment check works in some scenarios and not others. This creates more confusion than benefit.
2. IF cross env target support is added in the future, this check will become a blocker for CDK customers to set up cross env target.

@anan-k I will remove this check in all targets if you are not working on it already.

[samson-keung]

Closing this as a new one is opened for this.

[github-actions]

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.