feat(toolkit-lib): configurable stack event polling interval on deploy and destroy#1710
Merged
aws-cdk-automation merged 1 commit intoJul 7, 2026
Merged
Conversation
…y and destroy The StackActivityMonitor polls DescribeStackEvents every 2 seconds per active stack operation and the interval is not configurable. Large CI matrices driving toolkit-lib programmatically saturate the account-level CloudFormation read API and fail with throttling errors. Add an optional stackEventPollingInterval (milliseconds) to DeployOptions and DestroyOptions and thread it through Deployments and deployStack/destroyStack to the monitor. The default is unchanged (2000 ms). Closes aws#1709
mrgrain
approved these changes
Jul 7, 2026
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1710 +/- ##
==========================================
+ Coverage 89.61% 89.62% +0.01%
==========================================
Files 77 77
Lines 11752 11752
Branches 1650 1650
==========================================
+ Hits 10531 10533 +2
+ Misses 1192 1190 -2
Partials 29 29
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This was referenced Jul 8, 2026
amitaysh
pushed a commit
to amitaysh/aws-cdk-cli
that referenced
this pull request
Jul 12, 2026
…on deploy, destroy and prepareStack (aws#1724) Fixes aws#1723 ### Motivation Follow-on to aws#1709/aws#1710, which made the `StackActivityMonitor` event-polling interval (`DescribeStackEvents`) configurable via `stackEventPollingInterval`. There's a second hardcoded polling loop that wasn't touched: the stabilization waiter. `stabilizeStack()` in `lib/api/deployments/cfn-api.ts` — via the exported `waitForStackDeploy()`/`waitForStackDelete()` — calls the module-private `waitFor(valueProvider, timeout = 5000)`, polling `DescribeStacks` every 5s per in-flight stack to detect a terminal state, with no option threading to it. Programmatic consumers running large CI matrices who already slowed the event monitor via `stackEventPollingInterval` saw `DescribeStacks` from this stabilization loop become the dominant CloudFormation read-API caller instead, still triggering throttling. ### Design decision: one parameter, not two `stackEventPollingInterval` now governs both the event-polling and stabilization-polling intervals, rather than adding a new sibling parameter (e.g. `stackStabilizationPollingInterval`). Going with reuse over a second parameter to avoid growing the public options surface on `DeployOptions`/`DestroyOptions` for a distinction most consumers won't need to control separately — both loops exist to reduce `DescribeStack*` call volume against the same CloudFormation rate limit. Happy to split it into a separate parameter in a follow-up if maintainers would rather keep the two tunable independently. ### Changes - Added an optional `stabilizationPollingInterval`/`pollingInterval` parameter to `waitForStackDelete()`, `waitForStackDeploy()`, and `stabilizeStack()` in `cfn-api.ts`. Default unchanged (5000ms). - Threaded the existing `stackEventPollingInterval` option through to that new parameter — it already sits right beside the `waitForStackDeploy`/`waitForStackDelete` calls in `deploy-stack.ts` (deploy, destroy, and the delete-before-recreate path). - Threaded through: - `deployStack()`/`destroyStack()` in `deploy-stack.ts` (all three call sites: delete-before-recreate, post-deploy stabilization, post-destroy stabilization) - `Deployments.cleanupChangeSet()` (the change-set cleanup path, called from `prepareStack()` and from `Toolkit.deploy()` when a user declines the deploy confirmation prompt) - Updated doc comments on `stackEventPollingInterval` at each layer (`DeployOptions`, `DestroyOptions`, `DeployStackOptions` in both `deploy-stack.ts` and `deployments.ts`) to note it also governs stabilization polling. - No public API surface changes — `stackEventPollingInterval` already existed; only its scope of effect changed, and doc comments were updated to reflect that. ### Not included Per the issue, two call sites needed confirming during implementation: - `waitForStackDelete` from `Deployments.cleanupChangeSet` — **included** (see above). - The rollback path (`Deployments.rollbackStack`), which calls `stabilizeStack` directly — **deferred**. This is the same rollback monitor that aws#1710 explicitly deferred for event polling, so leaving it out here keeps this PR consistent with that scope. Happy to add `stackEventPollingInterval` support to `RollbackStackOptions` in a follow-up if maintainers want it included. ### Testing - New `cfn-api-stabilization-polling-interval.test.ts`: directly exercises `stabilizeStack`, `waitForStackDeploy`, and `waitForStackDelete` with fake timers, asserting `DescribeStacks` polling cadence at both the 5s default and a custom interval. - Extended `deploy-stack-polling-interval.test.ts`: asserts `deployStack()`/`destroyStack()` forward `stackEventPollingInterval` to `waitForStackDeploy`/`waitForStackDelete` as the stabilization interval, alongside the existing `StackActivityMonitor` assertions. - Extended `cloudformation-deployments.test.ts`: asserts `prepareStack()` forwards `stackEventPollingInterval` through `cleanupChangeSet()` to `waitForStackDelete`. --- By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1709
Motivation
StackActivityMonitorpollsDescribeStackEventsevery 2 seconds per active stack operation, and the interval is hardcoded. Programmatic consumers running large CI matrices (the Powertools for AWS Lambda (TypeScript) team reports ~50–100 concurrent stack operations) saturate the account-level CloudFormation read API and fail withCDK_TOOLKIT_E5500/CDK_TOOLKIT_E7900"Throttling: Rate exceeded".Of the placements proposed in the issue, this implements the per-action option on
DeployOptions/DestroyOptionsrather than a global setting onToolkitOptions, keeping the new surface scoped to the actions that construct the monitor.Changes
stackEventPollingInterval(milliseconds) onDeployOptionsandDestroyOptions.Toolkit.deploy()/Toolkit.destroy()→Deployments.deployStack()/destroyStack()→ the twonew StackActivityMonitor(...)construction sites indeploy-stack.ts. The monitor already supportedpollingInterval; this only wires it up.Deployments.rollbackStack). This PR covers the deploy and destroy paths from the issue; happy to extend toRollbackStackOptionshere or in a follow-up if preferred.Testing
deploy.test.ts,destroy.test.ts),Deploymentsforwarding (cloudformation-deployments.test.ts), and monitor construction (deploy-stack-polling-interval.test.ts), including asserting the default stays 2 s when the option is unset.deploy-stack.test.ts: they verify the props passed tonew StackActivityMonitor(...)by wrapping the constructor via a module-leveljest.mock, which jest hoists file-wide.deploy-stack.test.tsdoesn't install that mock, so adding it there would have changed the module graph for all ~60 existing tests in that file — a separate file keeps the mock's blast radius to just these four tests.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license