agent's upgrade schedule fired during the code freeze — 12 PR

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.

Not specified by the original author.

TL;DR

Reopen the original PR to keep the review thread, then exempt PRs with review activity from auto-close. The agent's stale rule only looked at push dates and ignored review events, so it closed a PR a human was actively reviewing. Closing and reopening destroyed the review context for no reason.

Error

agent auto-closed an upgrade PR as "stale" while a human was mid-review, then reopened an identical one the next day

Steps

1. Reopen the original PR instead of keeping the duplicate. Reopening restores the review thread and the approved CI run. Expected: the original PR is open again with its comments intact.
2. Close the duplicate the agent opened. Leave a comment pointing at the original so nobody reviews the wrong one. Expected: one canonical PR, no confusion.
3. Re-request the review. Ping the human reviewer on the reopened PR. Expected: the reviewer picks up where they left off instead of starting over.
4. Fix the stale rule. Exempt PRs with open review requests, recent review comments, or recent human comments from auto-close; require a warning comment days before any close. Expected: the rule configuration no longer targets PRs humans are touching.
5. Change the agent's behavior. The agent should comment asking whether the PR is still needed instead of closing it outright. Expected: humans get a nudge, not a surprise close.

Use this when

• A stale bot or agent closes PRs that have active reviewers
• Reopened duplicate PRs are piling up and review history is being lost
• You are configuring inactivity rules for an upgrade-agent workflow
• A human complains their in-progress review vanished

Not for this skill when

• The PR was genuinely abandoned with no activity from anyone - closing it was correct
• The close came from a human maintainer, not automation - talk to them instead
• You want to close old PRs deliberately - do it with a warning comment first

Variant phrasings

• stale bot closed my PR during review
• agent closed upgrade PR as stale while under review
• duplicate PR opened after stale close
• how to stop auto-close on PRs with reviewers

Why it happens

Stale rules usually key off the last push or last commit date. A human reviewing a PR does not push, so a PR can look "inactive" to the bot while a reviewer has it open in another tab. The agent then closes it, realizes the work is still needed, and opens an identical PR the next day - losing the review thread, the CI history, and the reviewer's goodwill.

Edge cases

• Some platforms treat a close/reopen as resetting the mergeable state - re-run CI after reopening before merging.
• If the human's review was a "request changes," reopening keeps that state; make sure the agent addresses the feedback instead of just reopening.
• Exemptions should also cover PRs labeled "do not stale" or "wip" - humans use labels to signal intent.
• Track how often the agent's closes get reverted; a high revert rate means the stale thresholds are too aggressive.

Provenance

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

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

Thread query: agent auto-closed an upgrade PR as "stale" while a human was mid-review, then reopened an identical one the next day

TL;DR:

Not specified by the original author.

TL;DR: Security updates always ship in their own PR, separate from every other bump. Split the security patch out of the grouped PR, merge and release it first, then deal with the major on its own timeline. Configure the agent to treat security-flagged updates as their own group with priority handling. A CVE fix must never wait on unrelated breakage.

agent grouped a security patch with a major upgrade; the security fix couldn't ship until the major's breakage was fixed

1. Identify the security-flagged update inside the grouped PR (advisory ID, CVE number, or the scanner's severity label). Expected: one clearly-labeled security bump among the grouped changes.

2. Cherry-pick just the security bump onto a fresh branch and open it as its own PR with the advisory reference in the body. Expected: a minimal PR containing only the security fix.

3. Run CI on the security PR alone and merge it as soon as it is green, on the normal release train or hotfix path. Expected: the CVE fix ships while the major is still being fixed.

4. Leave the major upgrade in its own PR to be fixed and reviewed on its own timeline. Expected: the major's breakage no longer blocks anything security-related.

5. Change the agent's grouping config so security-flagged updates always form their own group, separated from feature and major bumps, with automerge-on-green if your policy allows it. Expected: the next advisory arrives as a standalone PR by default.

Use this when

• a CVE fix is bundled with an unrelated major upgrade
• a security patch is blocked by someone else's breakage
• the agent groups all updates into one PR regardless of severity
• auditors ask why a known CVE sat unpatched for weeks

Not for this skill when

• the security fix itself requires the major upgrade (then they are genuinely coupled; document why)
• the "security" label is a false positive from the scanner (downgrade the severity first)
• your policy forbids automerge on security PRs (keep the separate PR, just review it manually)

Variant phrasings

• "security patch stuck behind major upgrade"
• "CVE fix blocked by grouped PR"
• "renovate grouped security update with major"
• "how to separate security updates from regular bumps"
• "dependabot security PR mixed with feature upgrades"

Why it happens

Grouping rules usually key on schedule or package, not severity, so a security patch lands in whatever group was forming that day. The agent sees one fewer PR as a win. But security fixes and major upgrades have opposite risk profiles: the patch must ship fast with minimal change, the major needs slow careful review. Bundling them forces the fast item to move at the slow item's pace, which is exactly backwards.

Edge cases

• Some advisories only publish a fix on the new major line; then the security PR legitimately includes a major. Say so in the PR body so reviewers know it is not optional.
• Backport branches may need the same security patch separately; check whether the advisory affects maintained older lines.
• Automerging security PRs can still break the build; keep the CI gate, just skip the human review queue when policy allows.
• If the scanner flags a devDependency CVE as critical, weigh exploitability before hotfixing; not every critical needs the fast lane.

Provenance

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

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

Thread query: agent grouped a security patch with a major upgrade; the security fix couldn't ship until the major's breakage was fixed

TL;DR: