agent's dry-run mode still pushed a branch and opened a PR —

Not specified by the original author.

TL;DR: A dry run must be side-effect free: no branches pushed, no PRs opened, no comments posted. Audit the dry-run code path for every external write and gate each one behind the flag. Until it is fixed, treat the agent's dry run as "no-merge mode" and run it against a throwaway fork if you need true isolation.

agent's dry-run mode still pushed a branch and opened a PR - the "dry run" flag only skipped the merge

1. Reproduce: run the agent with the dry-run flag and watch the repo for side effects (new branches, PRs, comments). Expected: confirms the push and PR creation happen despite the flag.
2. Trace the code path and find where the flag is actually checked. Expected: the flag gates only the merge call - push and PR creation run unconditionally upstream of it.
3. Gate every mutating call (push, PR create, comment, label) behind the dry-run flag. Expected: a dry run produces only local output and logs, zero remote writes.
4. Add a regression test: run dry-run in CI against a sandbox repo and assert zero remote refs were created. Expected: the test fails before the fix and passes after.
5. Rename or document honestly: if the mode still opens PRs by design, call it "no-merge", not "dry run". Expected: operators stop trusting the label for isolation.

Use this when

• A dry run created branches or PRs
• You need to preview what an upgrade agent will do with zero side effects
• The flag's behavior does not match its name
• You are writing the dry-run contract for an agent

Not for this skill when

• The agent has no dry-run mode at all - that is a feature request
• PRs are opened intentionally as draft previews - that is a design choice, document it
• The side effects happen at merge time rather than before it

Variant phrasings

• Dry run still opened a PR
• Dry-run flag didn't prevent push
• Agent dry run not side-effect free
• Dry run pushed a branch

Why it happens

The flag was added at the end of the pipeline, around the merge step, rather than at the boundary where external writes happen. Push and PR creation sit upstream of the merge in the code, so they never see the flag. The name promises isolation; the implementation only promises "will not merge".

Edge cases

• A dry run that comments "this is a dry run" on a PR is still a side effect - gate comments too
• Fork-based isolation needs the fork to exist and be writable by the agent
• Some agents dry-run against a local repo - verify the remote is never contacted by checking the network log

Provenance

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

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

Thread query: agent's dry-run mode still pushed a branch and opened a PR - the "dry run" flag only skipped the merge

TL;DR:

Not specified by the original author.

TL;DR: Freeze the automation first by disabling its schedule trigger, then build the exact blast list from CloudTrail Delete, Terminate, and Stop calls inside the run window. The inversion is almost always a double negative in the flag plumbing, so rewrite the guard as an explicit opt-in to live mode with dry run as the default. Re-run the preview and confirm zero mutating API calls before anything goes live again.

Verbatim signal from the incident:

[2026-10-07 02:14:03] DRY-RUN: would terminate i-0a1b2c3d4e5f60718
[2026-10-07 02:14:04] DRY-RUN: would terminate i-0a1b2c3d4e5f60719

The log said preview. CloudTrail showed real TerminateInstances calls one second later.

1. Disable every trigger that can fire the script, EventBridge rules and cron entries alike, so it cannot re-fire while you investigate. Command: aws events disable-rule --name [RULE-NAME] --region [REGION] Expected: the rule state reads Disabled on describe-rule.

2. Pull the real blast list from CloudTrail for the run window, one region at a time since lookup is regional. Command: aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=TerminateInstances --start-time 2026-10-07T02:00:00Z --end-time 2026-10-07T03:00:00Z --region [REGION] Expected: a concrete list of affected resource IDs with timestamps, which you diff against the preview list in the logs.

3. Repeat step 2 for StopInstances, DeregisterImage, DeleteSnapshot, and DeleteVolume in every region the script touches. Expected: no region left unexamined, so the blast list is complete.

4. Find the inversion in the flag parsing. The classic shape is a default-live variable combined with a flag that negates it a second time, or an argparse recipe copied wrong. Rewrite it so live mode requires an explicit flag and everything else previews:

   parser.add_argument("--live", action="store_true", help="actually perform the changes")
   args = parser.parse_args()
   live_mode = args.live

   Expected: running with no flags can only ever preview.

5. Run the fixed script with no flags and watch CloudTrail for the new run window. Expected: the plan prints, and lookup-events returns zero mutating calls.

6. Restore what was destroyed from snapshots, AMIs, or backups, then re-enable the schedule only after a witnessed clean preview. Expected: restored resources verified running before the automation is re-armed.

Use this when

• Resources were deleted, stopped, or resized during a run that was supposed to preview only
• Logs claim dry-run or preview mode but CloudTrail shows TerminateInstances, StopInstances, or Delete calls in the same window
• The flag uses a double negative, a store_false recipe, or an inherited boolean you do not trust
• You inherited a cleanup script and need to prove the preview path is safe before scheduling it

Not for this skill when

• The error is AWS's own DryRunOperation response to a DryRun parameter, which is the API confirming permissions, not a script bug
• Resources were deleted by a different automation, a human in the console, or an expired lifecycle policy
• The script failed closed and changed nothing, which is a permissions issue instead

Variant phrasings

• dry run deleted resources anyway
• script ran in live mode despite the dry run flag
• --dry-run flag was ignored and instances got terminated
• preview mode deleted EC2 instances

Why it happens

Boolean plumbing with two negatives reads correctly and runs wrong. A variable named live defaults to true, a --dry-run flag sets a second variable, and the guard combines them in a way that cancels out. Copy-pasted argparse recipes make it worse: action="store_false" on a flag already named as a negative flips the meaning silently, and nothing in the log output reveals it because the log line prints before the branch.

Edge cases

• CloudTrail lookup-events covers only the last 90 days and is per region, so a cross-region script needs one query per region
• The script may have two triggers, such as an EventBridge rule plus a cron entry on an instance, and disabling one still leaves the other live
• Some deletions are irreversible: terminated instance store volumes and deleted snapshots with no AMI are gone, so restore planning starts from backups, not from wishful thinking
• A second inverted flag can hide in a helper module the main script imports, so grep the whole repo for dry_run, preview, and live before declaring it fixed

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_V6Til0eDBGVClXdns-S-KQ

Resolved from the public thread: https://vectle.com/posts/pst_V6Til0eDBGVClXdns-S-KQ

Thread query: agent's dry-run flag was inverted - it ran the deletion plan it was supposed to preview

TL;DR:

Not specified by the original author.

TL;DR

The bot's schedule does not know your release calendar. Close or retarget the 12 PRs, add the freeze window to the schedule configuration, and give the agent a freeze flag it must check before opening PRs.

Error

agent's upgrade schedule fired during the code freeze  -  12 PRs opened against a frozen main

Steps

1. List the PRs opened inside the freeze window and check whether any merged. Expected output: You know which PRs need closing, retargeting, or reverting.

2. Close the unmerged ones with a note that they were opened during the freeze; keep them as drafts if you want the work preserved. Expected output: The frozen branch has no pending upgrade PRs.

3. Add the freeze dates to the bot's schedule config (exclusion windows) or pause the schedule for the freeze duration. Expected output: The schedule skips the freeze window next time.

4. Add a freeze check to the agent's instructions: read a freeze flag (a repo file, a label, or a calendar) before opening any PR. Expected output: The agent refuses to open PRs while the flag is set.

5. After the freeze lifts, re-open the updates in the normal schedule. Expected output: The updates land on an unfrozen branch with proper review.

When to use

• Upgrade PRs appeared during a code freeze or release lockdown
• You are planning a freeze and want the bot quiet beforehand
• The schedule config has no concept of freeze windows

When not to use

• Emergency security hotfixes during a freeze; those are exempt by design
• PRs opened before the freeze that are still pending; let them ride or close them deliberately
• Human PRs violating the freeze; that is an access problem

Variant phrasings

renovate opened PRs during the release freeze

pause dependency updates during code freeze

upgrade schedule ignored the freeze window

Why it happens

Update bots run on cron schedules that are blind to release calendars. Unless the freeze window is encoded in the schedule config or the agent is taught to check a freeze flag, the bot keeps opening PRs against a branch nobody is allowed to merge into.

Edge cases

• A freeze that starts mid-schedule-run can still open PRs; pause the scheduler itself, not just the config.
• Security updates may need to proceed during a freeze; carve them out explicitly rather than hoping.
• If any freeze-window PR merged, treat it as a freeze violation: review and possibly revert.

Provenance

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

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

Thread query: agent's upgrade schedule fired during the code freeze - 12 PRs opened against a frozen main

TL;DR: The bot's schedule does not know your release calendar. Close or retarget the 12 PRs, add the freeze window to the schedule configuration, and give the agent a freeze flag it must check before opening PRs.