agent closed a stale upgrade PR and opened a fresh one, losing the review thread and the approved CI run

Not specified by the original author.

TL;DR: Do not close and reopen to refresh a stale PR - update the existing branch in place by rebasing or merging main and pushing. Closing discards the review thread and the approved CI run, and the new PR starts from zero trust. If the old branch is truly unrecoverable, link the closed PR prominently in the new description and carry the review conclusions over.

agent closed a stale upgrade PR and opened a fresh one, losing the review thread and the approved CI run

1. Check whether the old PR's branch still exists and whether the PR can be reopened. Expected: you know if in-place recovery is possible or the branch is gone.
2. If the branch exists, reopen the old PR (or push the refreshed branch to it) and close the duplicate. Expected: a single PR carrying the full review and CI history.
3. If the branch is gone: in the new PR description, link the closed PR and paste the key review conclusions plus the approved CI run link. Expected: reviewers see the carried-over context without digging through closed PRs.
4. Re-run CI on the surviving PR and re-request review, noting explicitly what changed versus the closed one. Expected: fresh approvals on the actual code being merged - nothing carried over silently.
5. Teach the agent: stale PRs get refreshed in place; close-and-reopen is only for a corrupt branch, and then a link-back is mandatory. Expected: future stale PRs keep their threads.

Use this when

• An agent closed an upgrade PR and opened a duplicate
• Review comments or an approved CI run were lost in the shuffle
• You need to recover continuity between the old and new PR
• A bot or agent keeps "refreshing" PRs by closing them

Not for this skill when

• The PR was closed because the upgrade itself was abandoned - that is fine
• The new PR properly supersedes the old one with a link-back already in place
• Your workflow already refreshes PRs in place with rebases

Variant phrasings

• Agent reopened upgrade PR, lost review comments
• Closed stale PR and opened new one, lost approvals
• Duplicate upgrade PR
• Refresh by close-and-reopen lost CI history

Why it happens

The agent treats "stale" as "broken" and its refresh primitive is close-plus-open, because it does not model review threads and CI approvals as state that lives on the PR object. To the agent the diff is identical, so the new PR looks equivalent - but the human trust (reviews, green runs) was attached to the old PR number, not to the diff.

Edge cases

• Some repos auto-delete branches on close - restore the branch from the reflog or a local copy first
• If main moved on, the reopened PR needs a rebase anyway - watch for the approval-invalidation trap when you do
• Bots that auto-close stale PRs need an exemption label for agent upgrade PRs under active review

Provenance

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

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

Thread query: agent closed a stale upgrade PR and opened a fresh one, losing the review thread and the approved CI run

TL;DR:

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

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.