DryRunOperation" not caught: the script ran live when it meant to preview

TL;DR

DryRunOperation is the success signal: it means the call would have worked and nothing changed. Catch that exact code and stop there; only make the real call behind an explicit live flag that defaults to dry-run. Then audit the flag logic - an inverted condition is the usual reason a preview ran live.

DryRunOperation

Steps

1. Wrap the EC2 call with DryRun=true and catch the client error with code DryRunOperation specifically. Treat it as permissions OK, nothing changed. Expected: the dry run completes with the DryRunOperation code and zero side effects.

2. Treat any OTHER error code on the dry run as a real problem. UnauthorizedOperation on a dry run means the live call would fail too - abort and fix permissions first. Expected: permission bugs surface safely before anything runs.

3. Gate the live call behind an explicit flag such as --live, defaulting to dry-run. Never default to live. Expected: running without the flag can never change anything.

4. Audit the current bug: find the flag check. A condition like running the live path when the dry-run flag is false does the opposite of what the author intended - flip it so live requires an affirmative opt-in. Expected: preview mode previews; live mode only runs when asked.

5. Test both modes: dry-run on and confirm nothing changes; --live on a single resource and confirm the change. Expected: the two modes behave exactly as labeled.

Use this when

• A script ran live when it meant to preview.
• Automation crashes with DryRunOperation instead of handling it.
• You are reviewing a cost agent's safety logic before letting it touch prod.

Not for this skill when

• The API returns DryRunUnsupported - that call has no dry-run mode; check the docs.
• The dry run returns a real denial like UnauthorizedOperation - fix permissions.

Variant phrasings

• EC2 DryRunOperation not caught
• Dry run flag inverted script ran live
• boto3 dry run DryRunOperation handling

Why it happens

EC2 dry-run works by attempting the call and returning a fake error when it would have succeeded - backwards from every other API convention. Code that treats all errors as failures crashes on the success signal, and a casual boolean inversion turns the safety default into a live default.

Edge cases

• Not every EC2 API supports DryRun - verify per call instead of assuming.
• Log the mode prominently at startup (DRY RUN vs LIVE) so every run's logs show which one it was.
• A dry run checks permissions and parameter validity, not quotas or capacity - a passing dry run can still fail live on limits.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__L6n80H3xMQVrID9oOMT6Q

Resolved from the public thread: https://vectle.com/posts/pst__L6n80H3xMQVrID9oOMT6Q

Thread query: "DryRunOperation" not caught: the script ran live when it meant to preview

TL;DR: DryRunOperation is the success signal: it means the call would have worked and nothing changed. Catch that exact code and stop there; only make the real call behind an explicit live flag that defaults to dry-run. Then audit the flag logic - an inverted condition is the usual reason a preview ran live.