Summary
`maybeThrottleReviewNagPing` (`src/queue/processors.ts`) counts prior `@gittensory` pings via `countRecentAuditEventsForActorAndTarget(env, commenter, REVIEW_NAG_PING_EVENT_TYPE, targetKey, sinceIso)`, where `targetKey = `${repoFullName}#${issue.number}``. The count is scoped to the current PR/issue only.
Enforcement holds/closes the PR once the ping count reaches `reviewNagMaxPings`. Because the count is scoped per-target, a contributor who exhausts their pings on one PR can open a fresh PR — a new `issue.number` means a new `targetKey`, a clean `0/maxPings` slate, with zero memory of the prior PR's ping history.
This is inconsistent with the contributor blacklist and moderation-rules ban tally, both of which correctly persist by actor login across every PR, not per-thread.
The same gap exists in the sibling `maybeThrottleMonitoredMentions` (the per-maintainer-mention nag counter), which uses the same per-target scoping via a `targetKey` suffixed `#mention:`.
Scope
- Add a repo-scoped count query: total matching pings for an actor across every target in a repo (not one `targetKey`).
- Wire it into `maybeThrottleReviewNagPing` in place of the per-target count.
- Apply the analogous fix to `maybeThrottleMonitoredMentions`, preserving its per-mentioned-login independent budgets.
- Regression test: contributor exhausts pings on PR A (closed/held), opens PR B, confirm the throttle recognizes the carried-over count instead of starting fresh.
Why this matters
Without this fix, the review-nag cooldown is trivially defeated by opening a new PR — it only ever throttles a contributor within a single thread, never across their activity in a repo.
Summary
`maybeThrottleReviewNagPing` (`src/queue/processors.ts`) counts prior `@gittensory` pings via `countRecentAuditEventsForActorAndTarget(env, commenter, REVIEW_NAG_PING_EVENT_TYPE, targetKey, sinceIso)`, where `targetKey = `${repoFullName}#${issue.number}``. The count is scoped to the current PR/issue only.
Enforcement holds/closes the PR once the ping count reaches `reviewNagMaxPings`. Because the count is scoped per-target, a contributor who exhausts their pings on one PR can open a fresh PR — a new `issue.number` means a new `targetKey`, a clean `0/maxPings` slate, with zero memory of the prior PR's ping history.
This is inconsistent with the contributor blacklist and moderation-rules ban tally, both of which correctly persist by actor login across every PR, not per-thread.
The same gap exists in the sibling `maybeThrottleMonitoredMentions` (the per-maintainer-mention nag counter), which uses the same per-target scoping via a `targetKey` suffixed `#mention:`.
Scope
Why this matters
Without this fix, the review-nag cooldown is trivially defeated by opening a new PR — it only ever throttles a contributor within a single thread, never across their activity in a repo.