Skip to content

fix(pr-management-triage): guard Sweep 4 against freshly-promoted PRs#368

Merged
potiuk merged 1 commit into
apache:mainfrom
potiuk:fix-pr-triage-sweep4-ready-label-misfire
May 28, 2026
Merged

fix(pr-management-triage): guard Sweep 4 against freshly-promoted PRs#368
potiuk merged 1 commit into
apache:mainfrom
potiuk:fix-pr-triage-sweep4-ready-label-misfire

Conversation

@potiuk

@potiuk potiuk commented May 28, 2026

Copy link
Copy Markdown
Member

Summary

  • stale-sweeps.md Sweep 4 (stale ready-for-review label) was wrongly counting maintainer comments that predate the ready for maintainer review label-add as evidence of author silence. Tighten the "Common trigger" so it only fires when a maintainer comment postdates the label-add timestamp.
  • The fix mirrors the "after the label-add timestamp" pattern that classify-and-act.md row F4 already uses for regression detection — convention now consistent across the skill.

Why

When ready for maintainer review is added, the queue moves to the maintainers. Pre-label maintainer comments are part of the conversation that got the PR to ready, not proof of post-promotion silence. The naive check meant a PR promoted on day N could be closed on day N+2 by Sweep 4b — exactly backwards from what the label means.

Live incident

apache/airflow#66642 — contributor was promoted to ready for maintainer review on 2026-05-24 and closed on 2026-05-26 with "no author response for 15 days since the last maintainer comment". The cited maintainer comment was from 2026-05-11, well before the promotion. Contributor pushed back politely; PR reopened 2026-05-28; this PR is the skill-side fix.

Test plan

  • skill-and-tool-validate exits 0 (verified locally).
  • On the next morning sweep, confirm no freshly-promoted PR (< 7 days since label-add) appears as a Sweep 4 candidate.
  • On a real stale ready-labeled PR (label > 7d, maintainer comment AFTER label, author silent ≥ 7d), confirm Sweep 4b still fires correctly.

Sweep 4 (stale ready-for-review label) in stale-sweeps.md proposes
`strip-ready-label` (4a, healthy branch) or `close` (4b, rotted
branch) when a PR carries the `ready for maintainer review` label,
a maintainer commented ≥ 7 days ago, and the author has been
silent since.

The "maintainer commented ≥ 7 days ago" check was naive: it counted
ANY maintainer comment older than 7 days, including ones that
predate the `ready for maintainer review` label-add. So a PR that
was promoted to ready on day N could be closed by Sweep 4b on day
N+2 — because the maintainer comment that initially nudged the
contributor (and that the contributor's eventual fix addressed,
leading to the promotion) was now > 7 days old and the contributor
was, by definition, "silent" since.

This is backwards. When the `ready for maintainer review` label is
added, the queue moves to the maintainers; the author has nothing
they need to reply to. Pre-label maintainer comments are part of
the conversation that *got* the PR to ready, not evidence of
silence on something the author still owes.

== Fix ==

Sweep 4's "Common trigger" now requires the qualifying maintainer
comment to have come AFTER the label was added:

  last_maintainer_comment_at > ready_label_added_at

`ready_label_added_at` is the most recent
`LabeledEvent { label.name == "ready for maintainer review" }`
timestamp from the PR's `timelineItems`. If no maintainer has
commented post-promotion, the sweep doesn't fire at all — the
queue is on the maintainers, not the contributor.

The new guard mirrors the "after the label-add timestamp" pattern
that classify-and-act.md row F4 already uses for regression
detection, so the convention is consistent across the skill.

== Live incident motivating the fix ==

apache/airflow#66642 — contributor was promoted to
`ready for maintainer review` on 2026-05-24, closed by this
skill on 2026-05-26 with *"no author response for 15 days since
the last maintainer comment"*. The cited maintainer comment was
from 2026-05-11, well before the promotion. Contributor pushed
back politely; PR reopened 2026-05-28; this is the skill-side fix.

== Verification ==

`skill-and-tool-validate` exits 0.

Generated-by: Claude Code (Opus 4.7)
@potiuk potiuk merged commit fad7b0c into apache:main May 28, 2026
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant