Skip to content

simulate can silently truncate the PR crawl and undercount the payout denominator #5

Description

@Oyinkans0la12

fetchMergedPullRequests pages with sort=updated&direction=desc, caps at MAX_PAGES_PER_REPO = 10 (1000 PRs) per repo, and --max-prs defaults to 300. When a cap is reached the run succeeds, printing a confident table built from a subset of the window.

Two things make that dangerous rather than cosmetic:

  • The window filter uses merged_at while the listing is ordered by updated, so the pages that contain the window are not guaranteed to be reached before the cap. A dormant PR merged inside the window competes with every PR touched more recently.
  • The denominator is a sum of issuesClosed, so dropping PRs does not just hide rows — it changes every contributor's amount, while dustRemainder still looks plausible.

The --since default (previous cycle's generatedAt) and the 300 default make this reachable for a busy multi-repo cycle, and nothing in the output says the crawl was cut short.

Fix: detect exhaustion (cap hit while payload.length === PER_PAGE, or merged.length >= maxPrs) and warn loudly — or fail with a clear message pointing at --max-prs. A paging strategy anchored on the window (e.g. stopping once a page is entirely older than since, which needs sort consistent with the filter) would be the real cure.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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