Skip to content

auto-close-duplicates.ts reads only the first 30 comments and 30 reactions, silently ignoring objections on busy issues #80506

Description

@Serhii-Leniv

scripts/auto-close-duplicates.ts paginates the issues list, but its two other list reads use GitHub's default page size of 30 and never follow pagination:

  • comments: githubRequest(/repos/.../issues/${issue.number}/comments) (line 156) — first 30 comments only
  • reactions: githubRequest(/repos/.../issues/comments/${id}/reactions) (line 220) — first 30 reactions only

sweep.ts in the same directory passes per_page=100 on every list call, so this looks like an oversight rather than a choice.

Consequences

  1. A 👎 beyond the first 30 reactions is silently ignored. The anti-close protection reads only the first page, so on exactly the high-engagement issues the protection is for, it degrades: a dupe notice with 32 👍/❤️ followed by the author's 👎 auto-closes anyway. Real dupe notices are already near the cap — the notice on [BUG] Claude Code OAuth login times out after browser authorization and ends in internal server error #44252 has 23 👎, [BUG] Unhandled Case [object Object] #59033 has 20. This also undercuts auto-close-duplicates only honors a thumbs-down from the issue author, unlike what the bot comment promises #79146 / PR fix: honor thumbs-down from any user when skipping duplicate auto-close #79151: counting any user's 👎 doesn't help if that 👎 is on page 2.

  2. Human replies after a dupe notice at comment position 30 are invisible. The commentsAfterDupe activity check sees only the first 30 comments, so when the dupe notice is the 30th comment and people object afterwards, the issue closes despite the objections. Notices deep in a thread are a supported path: backfill-duplicate-comments.ts dispatches the dedupe workflow onto old issues that already have long comment threads.

  3. (fail-open) A dupe notice past position 30 is never seen at all, so those issues are silently exempt from auto-close — inconsistent with the intent, though harmless to reporters.

Repro

Mock-fetch harness emulating GitHub pagination semantics (default 30 without per_page), three fixture issues:

Current script: closed: [101, 102, 103] — two wrongful closes.
With pagination (per_page=100 + follow pages): closed: [103].

Fix

Add a small githubRequestAllPages helper and use it for both reads. PR incoming.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions