Issue/PR numbers are a global sequence, not per-repo — import made Gluecron.com's PRs jump #3527 → #5436#203
○Openccantynz opened this issue 24d ago
ccantynzAuthorcommented 24d ago
issues.number and pull_requests.number are serial columns — one global sequence across every repo on the platform. Two user-visible consequences, both surfaced by the 2026-08-07 bulk import:
The ~1,900 imported PRs on other repos consumed the shared counter, so Gluecron.com's next native PR jumped from #3527 to #5436. Owner spotted it and reasonably asked whether PRs had been copied.
Imported issues/PRs could not keep their original GitHub numbers, so historical references ("see PR #1543") don't resolve on the migrated repos.
Expected behavior (GitHub convention): numbering is per-repository, starting at #1.
Fix sketch: replace serial with a per-repo counter — e.g. a repo_counters table incremented in the same transaction as the insert (UPDATE ... RETURNING for atomicity), unique index on (repository_id, number). Migration needs care: existing rows keep their numbers (renumbering would break every existing URL/reference); only the allocation of new numbers becomes per-repo, seeded at max(number) per repo. The importer could then also preserve original GitHub numbers on fresh imports (they're per-repo and collision-free on a new repo).
Related: the "two sources of truth" family — the number a user sees vs the sequence that generates it.
c comment · e edit title · x close/reopen · ? shortcuts
issues.numberandpull_requests.numberareserialcolumns — one global sequence across every repo on the platform. Two user-visible consequences, both surfaced by the 2026-08-07 bulk import:Expected behavior (GitHub convention): numbering is per-repository, starting at #1.
Fix sketch: replace
serialwith a per-repo counter — e.g. arepo_counterstable incremented in the same transaction as the insert (UPDATE ... RETURNINGfor atomicity), unique index on(repository_id, number). Migration needs care: existing rows keep their numbers (renumbering would break every existing URL/reference); only the allocation of new numbers becomes per-repo, seeded atmax(number)per repo. The importer could then also preserve original GitHub numbers on fresh imports (they're per-repo and collision-free on a new repo).Related: the "two sources of truth" family — the number a user sees vs the sequence that generates it.