rolling-PR metadata recovery: automate close+reopen when a wrong-target mutation has already landed #279

New issue

Closed

opened 2026-07-02 09:39:49 +02:00 by quartermaster · 0 comments

quartermaster commented

2026-07-02 09:39:49 +02:00

Owner

Sibling axis of #274

Released as the follow-up tracker per the Set D dispatch (Bosun b1c3 ratified, operator (a)-authorized 2026-07-02). #274's fix in PR #277 — client-side head-ref filter in forgejo_find_pr_by_head — prevents future wrong-target mutations (the workflow won't PATCH a feature PR's title/body ever again). This tracker addresses the complementary axis: recovery when a wrong-target mutation has already landed (the empirical case: tmux-tell PR #711 is currently still showing chore(release): v0.29.0 as its title + assembled changelog body, even though its head is i/708-healthscan-adapter-resolver and it merged 2026-07-01 22:43).

Problem shape

After a wrong-target PATCH lands:

The wrongly-mutated PR carries substrate-mismatched metadata (title + body reflect a release, not the feature). Discovery confusion: the PR list shows two chore(release): vX.Y.Z PRs, one closed and one open. git log, tags, and release page are all correct — the mutation is Forgejo-PR-object-metadata only.
Manual recovery today: an operator PATCHes the title + body back to the original (which is only recoverable if someone remembers what they were, or dredges up the PR's initial creation event via the Forgejo audit log — not friendly).

Proposed fix direction — the "auto close+reopen" mechanism

Two dispositions worth considering (issue is deliberately scoped to file-the-tracker-for-discussion, not lock in a mechanism yet):

(A) Prevention-only — accept #274's client-side filter as the durable fix; treat existing corrupt-metadata PRs (e.g., tmux-tell#711) as historical residue that gets manually restored once per incident, no automated recovery machinery. Cheapest.
(B) Automated recovery — teach the rolling-PR update path to detect when the target PR's head.label doesn't match release-prep/rolling (defensive-in-depth on top of the client-side filter). If detected mid-flight, either close+reopen the target PR to reset its metadata to Forgejo's git-side truth, OR fetch the PR's original title/body from an audit log + re-PATCH to restore. Which specific mechanism is TBD — hence "close+reopen" as a naming placeholder pending mechanism design.
(C) Snapshot-first PATCH — before the wrong-target PATCH could ever happen, snapshot the target PR's current title + body into the workflow log. Recovery becomes "grep the workflow log + re-PATCH." Cheap; doesn't need a new API surface. But needs someone to notice + go look.

Recommendation — file for triage after the #274 fix in PR #277 lands and gets some empirical bake time. If no further wrong-target mutations happen (client-side filter holds), (A) is fine. If a recovery need surfaces, (B) or (C) become worth building.

Acceptance criteria

Dispositioned as (A) / (B) / (C) after PR #277 has some post-merge bake time (e.g., 2-3 release cycles clean).
If (B) or (C): mechanism designed + implemented + tested.
If (A): close as won't-do with the empirical anchor recorded.

Refs

Parent axis: release-toolkit#274 (wrong-target mutation prevention)
Fix PR: release-toolkit#277 (client-side head-ref filter)
Empirical residue: tmux-tell#711 — still shows mutated title+body
Set D milestone: release-toolkit#68 (this issue is the auto close+reopen follow-up filed per operator/Bosun 2026-07-02 ratification)

Anchor

Set D 2026-07-02 morning arc close, QM stewardship (alcatraz-infra QM task #658).

## Sibling axis of #274 Released as the follow-up tracker per the Set D dispatch (Bosun `b1c3` ratified, operator (a)-authorized 2026-07-02). #274's fix in [PR #277](https://git.frankenbit.de/frankenbit/release-toolkit/pulls/277) — client-side head-ref filter in `forgejo_find_pr_by_head` — **prevents future wrong-target mutations** (the workflow won't PATCH a feature PR's title/body ever again). This tracker addresses the **complementary axis: recovery when a wrong-target mutation has already landed** (the empirical case: tmux-tell PR #711 is currently still showing `chore(release): v0.29.0` as its title + assembled changelog body, even though its head is `i/708-healthscan-adapter-resolver` and it merged 2026-07-01 22:43). ## Problem shape After a wrong-target PATCH lands: 1. The **wrongly-mutated PR** carries substrate-mismatched metadata (title + body reflect a release, not the feature). Discovery confusion: the PR list shows two `chore(release): vX.Y.Z` PRs, one closed and one open. `git log`, tags, and release page are all correct — the mutation is Forgejo-PR-object-metadata only. 2. Manual recovery today: an operator PATCHes the title + body back to the original (which is only recoverable if someone remembers what they were, or dredges up the PR's initial creation event via the Forgejo audit log — not friendly). ## Proposed fix direction — the "auto close+reopen" mechanism Two dispositions worth considering (issue is deliberately scoped to **file-the-tracker-for-discussion**, not lock in a mechanism yet): - **(A) Prevention-only** — accept #274's client-side filter as the durable fix; treat existing corrupt-metadata PRs (e.g., tmux-tell#711) as historical residue that gets manually restored once per incident, no automated recovery machinery. Cheapest. - **(B) Automated recovery** — teach the rolling-PR update path to detect when the target PR's `head.label` doesn't match `release-prep/rolling` (defensive-in-depth on top of the client-side filter). If detected mid-flight, either close+reopen the target PR to reset its metadata to Forgejo's git-side truth, OR fetch the PR's original title/body from an audit log + re-PATCH to restore. Which specific mechanism is TBD — hence "close+reopen" as a naming placeholder pending mechanism design. - **(C) Snapshot-first PATCH** — before the wrong-target PATCH could ever happen, snapshot the target PR's current title + body into the workflow log. Recovery becomes "grep the workflow log + re-PATCH." Cheap; doesn't need a new API surface. But needs someone to notice + go look. **Recommendation** — file for triage after the #274 fix in PR #277 lands and gets some empirical bake time. If no further wrong-target mutations happen (client-side filter holds), (A) is fine. If a recovery need surfaces, (B) or (C) become worth building. ## Acceptance criteria 1. Dispositioned as (A) / (B) / (C) after PR #277 has some post-merge bake time (e.g., 2-3 release cycles clean). 2. If (B) or (C): mechanism designed + implemented + tested. 3. If (A): close as won't-do with the empirical anchor recorded. ## Refs - Parent axis: release-toolkit#274 (wrong-target mutation prevention) - Fix PR: release-toolkit#277 (client-side head-ref filter) - Empirical residue: [tmux-tell#711](https://git.frankenbit.de/frankenbit/tmux-tell/pulls/711) — still shows mutated title+body - Set D milestone: release-toolkit#68 (this issue is the auto close+reopen follow-up filed per operator/Bosun 2026-07-02 ratification) ## Anchor Set D 2026-07-02 morning arc close, QM stewardship (alcatraz-infra QM task #658).

quartermaster added this to the Set D — Toil drain milestone

2026-07-02 09:39:49 +02:00