fix(custom-resources): waiter state machine retry fails with ExecutionAlreadyExists

[newlinedeveloper]

Description

Fixes an issue where retrying a CloudFormation deployment that uses a custom resource with an async waiter fails with ExecutionAlreadyExists error.

Root Cause

The custom resource provider framework uses CloudFormation's RequestId as the Step Functions execution name when starting the waiter state machine. When CloudFormation retries a failed deployment, it reuses the same RequestId. Since Step Functions execution names must be unique for 90 days, subsequent retry attempts fail with ExecutionAlreadyExists.

Solution

Removed the name parameter from the startExecution call, allowing Step Functions to auto-generate unique execution names. This is the recommended approach per the AWS Step Functions StartExecution API Reference, where the name parameter is optional and Step Functions will automatically generate a universally unique identifier (UUID) as the execution name if not provided.

Changes

• Removed name: resourceEvent.RequestId from the waiter state machine execution call in framework.ts
• Updated log statement to remove the name field
• Added unit test to verify that name is not included in the startExecution call

Testing

• Added unit test waiter state machine execution does not include name field (allows retries) to verify the fix
• All existing unit tests pass
• Verified that the mock assertion checks for name being undefined

Related Issue

Fixes #35957

Verification

The fix was verified by:

1. Running unit tests to ensure the name field is not included
2. Confirming that existing tests continue to pass
3. The change aligns with AWS Step Functions best practices for execution naming

---

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

[aws-cdk-automation]

(This review is outdated)

[newlinedeveloper]

Exemption Request

This fix is in runtime code (Lambda function execution) and does not change CloudFormation templates or infrastructure. The existing integration tests verify infrastructure creation, which is unaffected by this change. Unit tests provide comprehensive coverage of the runtime behavior change.

[vvigilante]

alternatively we could forward the request id from the lambda. That should never repeat.

[Abogical]

I have confirmed that this PR fixes the issue.

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

Pull request has been modified.

[mrgrain]

Integration test failure are expected due to the changed asset. They are not caused by the new integ-runner engine. You'll need to work with your PR reviewer to update all snapshots. For framework changes like this, I'd typically recommend that a CDK team member is doing this for you.