An approval can be invalidated by something that happens outside the PR — a different PR merging and superseding it — and every dismissal path tend has requires an event on the approved PR. So the approval stays standing indefinitely, and the sessions that do notice the supersession have no rule pointing them at it.
The gap
All three dismissal sites are keyed on activity on the approved PR itself:
nightly and resolve-conflicts contain no occurrence of "approv" or "dismiss" at all — and nightly's Step 3 conflict pass is precisely the session that discovers a supersession, because a superseded dependency PR usually surfaces as a conflict first.
Nothing here is wrong on its own; the union just has a hole where the invalidating event is another PR merging.
What it did on PRQL/prql
Dependabot #6259 (pyo3 0.27.2 → 0.28.3) drew a bot APPROVED on 2026-08-31. On 2026-09-03 the bot's own #6271 merged, taking pyo3 to 0.29.2 and carrying the same FromPyObject opt-in that sits on that branch — so PRQL/prql#6259 became a downgrade of a workspace pin, still reading APPROVED by the same account that wrote the superseding PR.
Two tend-nightly sessions read the PR after that and left the approval standing, each having stated the invalidating fact in its own summary:
- 33724512894 (2026-09-03): "merging it as-is would leave the pair split the other way".
- 33845444960 (2026-09-04): "It's also fully superseded —
#6271 merged this morning taking pyo3 to 0.29.2 and carrying the same from_py_object fix".
Neither posted a review, both deliberately (a deferral comment already stood, and restating it would be noise) — which is correct under the dedup rules and is exactly why #1136's posting-site rule never fired. The approval stood for four days and was only cleared by hand today, by a review-runs session.
The exposure was bounded here because the branch is CONFLICTING, so GitHub blocked the merge. That bound is incidental: a dependency PR superseded by a bump that doesn't touch the same manifest lines stays mergeable, and then there is nothing between the stale approval and a merge.
Shape of a fix
The trigger that's missing is "this session concluded an approved PR should not merge, for a reason that isn't a push and isn't a red check". A worked standing_approval_id field already exists in bot-review-state.sh from #1136 and reads "" once cleared, so the mechanism is there — what's missing is a site that consults it. nightly's Step 3 and resolve-conflicts look like the natural homes, since a superseded PR is usually a conflicted one.
One caution from the observed case: the rule should be about the standing approval specifically, not about commenting. Both sessions were right not to post a second deferral comment; the dismissal needs to be reachable independently of whether a comment or review is posted, or the dedup rules will keep suppressing it.
An approval can be invalidated by something that happens outside the PR — a different PR merging and superseding it — and every dismissal path tend has requires an event on the approved PR. So the approval stays standing indefinitely, and the sessions that do notice the supersession have no rule pointing them at it.
The gap
All three dismissal sites are keyed on activity on the approved PR itself:
skills/review/SKILL.md#L229— fix(review): dismiss a standing bot approval when the review withholds the verdict #1136's rule fires "whenever this round posts a COMMENT that withholds the verdict", so it needs a review round, which needs a push.skills/weekly/SKILL.md#L72— keyed onstale_approval_id, which by its own comment is set only when the deciding approval "predates the newest rewrite". No rewrite, no dismissal.skills/review/SKILL.md#L436— step 7's dismiss-on-red, live only while the approving session is still polling.nightlyandresolve-conflictscontain no occurrence of "approv" or "dismiss" at all — andnightly's Step 3 conflict pass is precisely the session that discovers a supersession, because a superseded dependency PR usually surfaces as a conflict first.Nothing here is wrong on its own; the union just has a hole where the invalidating event is another PR merging.
What it did on
PRQL/prqlDependabot #6259 (
pyo30.27.2 → 0.28.3) drew a botAPPROVEDon 2026-08-31. On 2026-09-03 the bot's own #6271 merged, takingpyo3to 0.29.2 and carrying the sameFromPyObjectopt-in that sits on that branch — soPRQL/prql#6259became a downgrade of a workspace pin, still readingAPPROVEDby the same account that wrote the superseding PR.Two
tend-nightlysessions read the PR after that and left the approval standing, each having stated the invalidating fact in its own summary:#6271merged this morning takingpyo3to 0.29.2 and carrying the samefrom_py_objectfix".Neither posted a review, both deliberately (a deferral comment already stood, and restating it would be noise) — which is correct under the dedup rules and is exactly why #1136's posting-site rule never fired. The approval stood for four days and was only cleared by hand today, by a
review-runssession.The exposure was bounded here because the branch is
CONFLICTING, so GitHub blocked the merge. That bound is incidental: a dependency PR superseded by a bump that doesn't touch the same manifest lines stays mergeable, and then there is nothing between the stale approval and a merge.Shape of a fix
The trigger that's missing is "this session concluded an approved PR should not merge, for a reason that isn't a push and isn't a red check". A worked
standing_approval_idfield already exists inbot-review-state.shfrom #1136 and reads""once cleared, so the mechanism is there — what's missing is a site that consults it.nightly's Step 3 andresolve-conflictslook like the natural homes, since a superseded PR is usually a conflicted one.One caution from the observed case: the rule should be about the standing approval specifically, not about commenting. Both sessions were right not to post a second deferral comment; the dismissal needs to be reachable independently of whether a comment or review is posted, or the dedup rules will keep suppressing it.