[HowardBraham]

Description

Current state. When a release branch is cut while an older release is still in flight, the release-changelog updater can list a PR that already shipped in the older release.

The newer branch merges the older one with -s ours, so the Runway cherry-pick commit is in the generator's range. The original PR is in range too, because it merged to main before the newer cut. The generator only compares PR numbers against the changelog text, so if the older release's changelog is stale or was hand-edited under the cherry-pick's number, the original is generated again.

This happened in the 13.56.0 and 8.19.0 cuts: Extension listed #47395 in both 13.55.0 and 13.56.0, and Mobile listed 14 PRs in both 8.18.0 and 8.19.0 (plus #37860, which belongs in 8.18.0).

Solution. When the baseline is not the target branch, the updater now:

• reads the generator's accepted ... cherry-pick=true diagnostics and keeps the cherry-pick commits that are reachable from the baseline ref (git merge-base --is-ancestor; a Git failure logs a warning and counts as not reachable, so the PR stays listed);
• removes the entries of those commits' canonical PRs, and of their cherry-pick PR numbers, from the generated section. An entry is removed only when every PR it owns is excluded, so an unrelated PR sharing an entry is never dropped;
• skips PRs that a reviewer already approved in the open changelog PR, because the updater restores those entries anyway;
• warns, in the log and the changelog PR body, about any left-out PR that no other section lists under its own number or a cherry-pick's, so a missing entry is visible instead of silently dropped.

It also restores the executable bit on .github/scripts/update-release-changelog.sh, which #303 changed from 100755 to 100644. Callers that exec the shim directly, such as Mobile's old release/8.18.0 wrapper, fail with exit 126 without it.

Limits:

• The rule applies on every run until the target branch has its own ## [version] section, not only the first. Reruns while the changelog PR is open keep reviewed entries, as above. Once the target has its own section, the updater preserves it and the rule no longer applies, so duplicates already in a merged section are not stripped.
• The PR body warning is rewritten by a later run, which can remove it. It stays in the run log.
• The warning is advisory; nothing blocks the PR.

Testing

Unit tests cover the helpers, the exclusion function (shared entries, reviewed PRs, PRs the section never listed), removeReleaseEntries, the warning wording, and the real git merge-base call against a temporary repository. The baseline.kind !== 'target' check in main() is covered only by the fork runs below.

Fork runs on real pre-cut commits, with the updater workflow adapted only to use PR_TOKEN and a hardcoded upstream URL. They ran on the first version of this change, before the review fixes above:

• Mobile (consensys-test/metamask-mobile-howard, release/8.18.0 at e553422d7, release/8.19.0 at 3fb2c3da5). With v1.22.0 the generated [8.19.0] section lists all 15 PRs (run 41933261975). With this change none are listed, and no other PR number differs (run 41934216310).
• Extension (consensys-test/metamask-extension-howard, release/13.55.0 at 3c4ab5e5e2, release/13.56.0 at e03bdce708). With v1.22.0 [13.56.0] lists #47395 (run 41936435434). With this change it does not, and the log and PR body warn that the 13.55.0 changelog does not list it (run 41939257564).

Related

See #303.

---

Note

Medium Risk
Changes release changelog output for overlapping release branches; mistaken reachability or alias handling could omit entries, though Git errors conservatively keep PRs listed and warnings flag gaps in older changelog sections.

Overview
When a newer release branch is cut while an older one is still active, update-release-changelog could list the same PR twice because cherry-pick commits sit in the generator range even though they already shipped on the baseline branch.

After auto-changelog runs, the updater now parses cherry-pick=true diagnostics, finds cherry-picks whose commits are ancestors of the baseline ref via git merge-base --is-ancestor, and strips matching entries from the draft section using new removeReleaseEntries (only when every PR on an entry is excluded; reviewer-approved lines are preserved). Excluded PRs that never appear anywhere else in the changelog trigger a console warning and an advisory quote on the changelog PR body. This path runs only while the baseline is not the target release itself.

Unit tests cover entry removal, exclusion edge cases, reachability (including Git failures), and PR presentation wording.

^{Reviewed by Cursor Bugbot for commit e28cd86. Bugbot is set up for automated code reviews on this repo. Configure here.}