GLOOK-26: fix PR undercount in get_metric_timeseries (per-repo PR numbers) - #60
Merged
Merged
Conversation
…OOK-26) GitHub PR numbers restart at #1 per repo, so grouping the prs metric by pr_number alone collapsed PR #42 in repo A with PR #42 in repo B. Cross-report over the default 180-day window this compounded badly: every repo has low PR numbers, so pr_number 1..~100 each absorbed hundreds of distinct PRs bucketed at their earliest appearance — starving recent weeks and capping the series at roughly the range of PR numbers (~5x undercount). Key the prs metric on (repo, pr_number) in both the report-grouped COUNT(DISTINCT ...) and the week/month/dimension dedup GROUP BY. commit_sha and issue_key are globally unique and unchanged. Verified on real data: recent weekly PR counts corrected ~4-5x (e.g. 2026-06-08 34 -> 197), matching sum(developer_stats.total_prs). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes a significant undercount in the
get_metric_timeseriesMCP tool'sprsmetric.Root cause: GitHub PR numbers restart at #1 in every repo, so
pr_numberis only unique within a repo — the true key is(repo, pr_number). The metric grouped by barepr_number, collapsing PR #42 in repo A with PR #42 in repo B. Cross-report over the default 180-day window this compounded badly: with ~600 repos, low PR numbers (1–~100) each absorbed hundreds of distinct PRs, all bucketed at the earliest date that number ever appeared. Result: recent weeks were starved (their low-numbered PRs were "already counted" months earlier) and the series capped near the range of PR numbers — a ~5× undercount.Fix: key the
prsmetric on(repo, pr_number)in both aggregation paths:group_by=report:COUNT(DISTINCT ca.repo, ca.pr_number)week/month/dimension dedup:GROUP BY ca.repo, ca.pr_numbercommit_shaandissue_keyare globally unique, so thecommits/jira_resolvedpaths are unchanged.Verification
tsc --noEmitclean; 2 tests updated/added asserting the(repo, pr_number)keying.COUNT(DISTINCT pr_number)=354 vsCOUNT(DISTINCT repo, pr_number)=452, matchingsum(developer_stats.total_prs)=467. PR #99 alone appeared in 4 repos.Notes
The same per-repo-number pattern exists in GLOOK-25's project-insights drill-down (
commitsByPrkeyed bypr_numberwithin a single report) — much smaller impact (single report, display not counting), left out to keep this focused. Worth a follow-up.🤖 Generated with Claude Code