Silent in-session de-dup of already-seen / already-skipped PRs

[potiuk]

If a PR was already inspected or skipped earlier in the same triage session — e.g. it was updated by the author mid-triage and reappears in a later page of results — skip it silently. No "you already saw this" prompt; just don't re-process.

Why: these reappearances generate noise and trick the operator into re-doing the same decision, sometimes with a different outcome from the first pass.

Acceptance

• Maintain an in-session set of PR IDs already touched (any terminal classification: applied, skipped, deferred, auto-skipped).
• On re-encounter within the same session: drop without surfacing in the queue or in the progress output.
• The set lives only for the session — a fresh session starts empty.

[potiuk]

Status check against main — still valid, but the scenario in the description no longer happens. The underlying defect does, and is arguably worse.

The stated scenario is defused. Step 1 now walks every page before classification or presentation (fetch-and-batch.md:201-203) and hands the accumulated list to Step 2. So a PR cannot "reappear in a later page of results" mid-triage — pagination is finished before any decision is made. Anyone checking this issue against the current design would reasonably close it as no-longer-applicable.

But there is a real duplicate, one level down. The search is sort:updated-asc (:127) and the loop is a bare accumulate with no dedup:

all_prs.extend(result.search.nodes)

With an ascending sort on update time, a PR updated during the multi-page walk jumps to the end of the ordering. A PR already fetched on page 1 can therefore land again on the last page and appear twice in all_prs — so the operator sees it twice in the same group listing, and can make two different decisions about it in one session. That is the harm this issue describes, reached by a different route.

The window is small but not negligible: bot pushes, CI status updates and comments all bump updated, and the loop can span many pages (the doc budgets for 50 × 20 = 1000 PRs at :243).

Remaining work, restated: dedupe all_prs by PR number after the pagination loop — keeping the last occurrence, since it carries the fresher snapshot. The proposed in-session "already touched" set is no longer the right shape, because there is no interleaving left to guard against.

Leaving open with the scenario rewritten.

[awishere]

Hi, I'd like to work on this. I'll deduplicate fetched PRs by number, keep the freshest occurrence, and add regression coverage.

[potiuk]

Re-opened after #1071 merged. #1071 closed this via keyword, but it
covers only part of what this issue asks for, and the remainder needs a
decision rather than more code.

What #1071 did: deduplicated the accumulated PR list by number after
the full-pagination loop, keeping each PR's freshest occurrence. That
addresses the mechanism named in this issue's example — a PR updated
mid-triage reappearing on a later page.

Against the acceptance criteria:

• "Maintain an in-session set of PR IDs already touched" — already
  satisfied before fix(pr-management-triage): dedupe paginated PRs #1071, by the session cache
  (fetch-and-batch.md section Session cache: prs.<n>.action_taken /
  action_at).
• "The set lives only for the session" — also already satisfied
  ("Discard the entire bundle on session exit").
• "On re-encounter within the same session: drop without surfacing" —
  not done. fix(pr-management-triage): dedupe paginated PRs #1071's seen_numbers is local to one fetch pass and
  discarded, so a PR already acted on earlier in the session is not
  suppressed.

Why the remaining criterion needs re-scoping rather than implementing:
it conflicts with the session cache's own invalidation rule —

An entry's head_sha must match the head SHA returned by the current
fetch — if it doesn't, the contributor pushed since and the entry is
stale. Drop it and re-classify.

An updated PR is deliberately re-processed, because new commits warrant
a fresh read. But an updated PR is also precisely the case this issue
wants suppressed. Both behaviours cannot hold at once.

A plausible resolution: suppress silently only when the head SHA is
unchanged since the terminal action (nothing new to read), and
re-classify when it changed (new commits deserve a look). That would
make the two rules complementary. If that is the intent, this issue
should be re-scoped to say so; if re-classifying updated PRs is
preferred, this can be closed as done.