Skip to content

Fail on duplicate incident ids, and give contributors a way to allocate one - #124

Open
emmanuelgjr wants to merge 1 commit into
mainfrom
feat/incident-id-guard
Open

emmanuelgjr wants to merge 1 commit into
mainfrom
feat/incident-id-guard

Conversation

@emmanuelgjr

Copy link
Copy Markdown
Contributor

Item 4, second half. Do not merge yet.

Why

INC-132 was allocated twice — by #117 and by #109 — because both read the end of data/incidents.json while the other was open. The second one found out when the merge conflicted. Beyond the conflict, a duplicate id silently breaks anything that resolves an incident by id: the webapp deep link, the evidence join, the reports.

What

  • validate.jscheckIncidentIds() — fails on a duplicate and names it. Also reports unused numbers, since a gap plus a duplicate is how a renumbering goes wrong.
  • scripts/next-incident-id.mjs — prints a free id. --check-prs also accounts for ids claimed by open pull requests, which is exactly what would have prevented this collision:
$ node scripts/next-incident-id.mjs --check-prs
INC-136
  highest in data/incidents.json: INC-134
  claimed by PR #122: INC-135

That is the id I have asked #109 to renumber to.

A deliberate testing choice

The duplicate case is not tested by mutating data/incidents.json. node --test runs suites in parallel, so writing to the shared corpus races the suites reading it — a bug this repository has already had once. I wrote that test first, watched it take 5 unrelated suites down with it, and replaced it.

Covered instead by: a corpus-uniqueness test, a wiring test (the guard exists, is called, and still fails on a duplicate), and a by-hand negative test when it was written — injecting a duplicate made validate.js exit 1 with INC-006 is used by 2 records.

Verification

Before After
validate.js 0 errors, 88 warnings, 327 passed 0 errors, 88 warnings, 328 passed
npm run test:scripts 85/85 89/89, run twice

🤖 Generated with Claude Code

…te one

INC-132 was allocated twice - by #117 and by #109 - because both read the end
of data/incidents.json while the other was open, and the second one only found
out when the merge conflicted. A duplicate id also silently breaks anything
that resolves an incident by id: the webapp deep link, the evidence join, the
reports.

validate.js gains checkIncidentIds(), which fails on a duplicate and names it.
scripts/next-incident-id.mjs prints a free id; --check-prs also accounts for
ids claimed by open pull requests, which is what would have caught this one -
it currently reports INC-136, because INC-135 is claimed by open PR #122.

The duplicate case is deliberately not tested by mutating data/incidents.json:
node --test runs suites in parallel, so writing to the shared corpus races the
suites reading it, which is a bug this repository has already had. The guard is
covered by a corpus-uniqueness test and a wiring test instead, and was
negative-tested by hand: injecting a duplicate made validate.js exit 1 with
"INC-006 is used by 2 records".

Baseline before: 0 errors, 88 warnings, 327 passed; 85/85 tests.
Baseline after : 0 errors, 88 warnings, 328 passed; 89/89 tests, twice.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant