[Bug]: openIssuesTotal under-counts when open PRs are subtracted from GraphQL issues

[dearsishs]

[Bug]: openIssuesTotal under-counts when open PRs are subtracted from GraphQL issue totals

Summary

For repositories with any open pull requests, persisting openIssuesTotal as repository.issues(states: OPEN).totalCount - repository.openPullRequests(states: OPEN).totalCount records too few open issues.

GitHub GraphQL repository.issues is an IssueConnection for issues; open pull requests are already exposed separately through repository.pullRequests. Subtracting PR totals double-excludes PRs and depresses the authoritative expected count used by the open-issue backfill pipeline.

Failure mode (concrete example)

A repo with 10 open issues and 3 open PRs:

• GraphQL issues(states: OPEN).totalCount → 10 (issues only)
• GraphQL pullRequests(states: OPEN).totalCount → 3
• Incorrect formula 10 - 3 → persists openIssuesTotal: **7**

Downstream effects:

• Repo summaries and decision packs show too few open issues.
• expectedForRequiredSegment("open_issues", …) in src/signals/data-quality.ts uses the depressed total.
• supplementUnderCountIfNeeded in src/github/backfill.ts may not run when REST already fetched ≥7 real issues but <10, so missing issues are never supplemented.

This is analogous to bounty validators needing authoritative closure data in issue_competitions/forward.py — here the sync forward pass must not corrupt the expected open-issue count.

Steps to reproduce

1. Register a repo with 10 open issues and 3 open PRs (GraphQL totals as above).
2. Run refreshRepoGithubTotals with PR-subtraction logic (or compare to REST issue-only crawl).
3. Observe openIssuesTotal: 7 in repo_github_totals_snapshots.

Expected behavior

openIssuesTotal equals open issues only, e.g. query issues(states: OPEN, filter: {issueTypes: ISSUE}) without subtracting pullRequests.

Actual behavior

Subtracting open PR count from the issues connection total under-counts open issues and breaks supplement/complete logic.

Suggested fix

• Query issues(states: OPEN, filter: {issueTypes: ISSUE}) for totals and GraphQL supplement.
• Do not subtract openPullRequests.totalCount from issues.totalCount.
• Skip any PullRequest nodes if they appear in supplement pagination.

[dosubot]

This issue appears to be based on an incorrect premise. Looking at the actual implementation of refreshRepoGithubTotals in src/github/backfill.ts, no PR subtraction is performed.

The code queries GitHub's GraphQL API with issues(states: OPEN) and stores the totalCount directly as openIssuesTotal [1]. Pull requests are tracked via a separate pullRequests(states: OPEN) connection and stored independently as openPullRequestsTotal — the two values are never combined or subtracted.

In GitHub's GraphQL schema, repository.issues is already an issue-only connection that does not include pull requests (unlike the REST /issues endpoint, which does conflate them). The REST backfill pipeline separately handles that difference by filtering out pull_request entries at line ~857 [2].

This was addressed in the same way in issue #80 [3], which reported the inverse misconception (that openIssuesTotal was over-counting by including PRs). That issue was also filed by you 2 days ago.

If you're observing an actual discrepancy for a specific repo, could you share the exact repo and the numbers you're seeing? That would help determine if there's a real data staleness or API inconsistency at play.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[JSONbored]

Closing as resolved — the buggy issues.totalCount - openPullRequests.totalCount formula is no longer in the code. src/github/backfill.ts persists the GraphQL issues(states: OPEN).totalCount directly and tracks open PRs separately, which matches this issue's suggested fix. (#160 and #176 remain open as distinct accounting bugs.)