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.

[newlinedeveloper]

Hi @Abogical @pahud , Need review and approval for this PR to be closed . Thanks

[Abogical]

the linter has passed but you'll need to update the integ test snapshots. See https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md#running-integration-tests

yarn integ-runner --directory packages/@aws-cdk --update-on-failed

[Abogical]

I've updated the snapshots to your PR branch directly.

[Abogical]

@newlinedeveloper
There are other snapshots to be uploaded but I don't have access to push LFS files to your fork. Can you merge this PR which will push the changes to your fork? newlinedeveloper#1

Pull request has been modified.

[Abogical]

For the record, only 2 snapshots failed to deploy with the new snapshot changes by the Gtihub workflow. Deploying them locally however works:

• packages/@aws-cdk-testing/framework-integ/test/aws-codebuild/test/integ.project-fleet.js
• packages/@aws-cdk-testing/framework-integ/test/aws-dynamodb/test/integ.global.js

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[mergify]

Merge Queue Status

✅ The pull request has been merged at 551220d

This pull request spent 5 seconds in the queue, with no time running CI.
The checks were run in-place.

Required conditions to merge

• #approved-reviews-by >= 1 [🛡 GitHub branch protection]
  • fix(custom-resources): waiter state machine retry fails with ExecutionAlreadyExists #35988
• #changes-requested-reviews-by = 0 [🛡 GitHub branch protection]
  • fix(custom-resources): waiter state machine retry fails with ExecutionAlreadyExists #35988
• any of [🛡 GitHub branch protection]:
  • check-success = validate-pr
  • check-neutral = validate-pr
  • check-skipped = validate-pr
• any of [🛡 GitHub branch protection]:
  • check-success = build
  • check-neutral = build
  • check-skipped = build

[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.