[Bug]: Monolithic backfill stores PR-inclusive count as openIssuesCount

[glorysr1209-png]

[Bug]: Monolithic backfill stores PR-inclusive count as openIssuesCount

Description

backfillRepository() paginates /issues, which returns both issues and pull requests. The sync state used issuePage.fetchedCount (raw page size) for openIssuesCount instead of filtering out pull_request entries.

That inflates open-issue metrics and breaks downstream logic that compares observed issue counts to required segments (supplementUnderCountIfNeeded / expectedForRequiredSegment).

Steps to reproduce

1. Backfill a repo where the issues page includes open PRs alongside issues.
2. Compare stored openIssuesCount to GitHub's open issue count.

Expected behavior

openIssuesCount and snapshot openIssues use issues.filter(i => !i.pull_request).length.

Actual behavior

PRs are counted as open issues.

Impact

Incorrect repo sync metrics and under/over-count compensation in the data spine.

[dosubot]

I can confirm this bug exists. The root cause is at line 1398 in the backfill logic [1]:

openIssuesCount: issuePage.fetchedCount,

fetchedCount is accumulated from the raw items.length in the githubPaged helper [2], which includes both issues and PRs returned by /issues?state=open. Meanwhile, items are correctly filtered before storage:

const issues = issuePage.items.filter((issue) => !issue.pull_request);

[3]

So the database gets only true issues, but openIssuesCount reflects the unfiltered total — causing the inflation you described.

Downstream impact:

• supplementUnderCountIfNeeded compares fetchedCount >= expectedCount [4] — an inflated count can cause necessary GraphQL supplementation to be skipped.
• buildCoreSignalFidelity uses openIssuesCount to evaluate data completeness against expectedForRequiredSegment [5] [6], propagating the error into system-wide status assessments.

Related work: PR #162 addresses a similar PR-inclusion bug on the GraphQL side using issueTypes: ISSUE, but it does not fix this REST-side fetchedCount issue.

The fix would be to use the filtered array length instead of issuePage.fetchedCount when storing openIssuesCount — something like tracking a cumulative count of just the filtered issues across pages. It's also worth checking if the same pattern affects openIssuesCount at the snapshot level (line 1417 appears to use the same inflated value).

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[JSONbored]

Closing — fixed. src/github/backfill.ts now computes the open-issue count from payloads.filter((issue) => !issue.pull_request), explicitly excluding pull requests, and persists via countOpenIssues (a dedicated issue-only counter). The PR-inclusive count bug no longer applies.