Development record
TestSurpriseRefusesAnUnresolvedOccasion failed in the merge queue on 2026-10-09 (PR #880, macOS race lane, run 37980092117) with 'duplicate issue id: srp-2610092000060599 already exists in this ledger; the mint collided with a record already committed': the test mints three surprise records in quick succession, two drew the same timestamp-plus-four-digit id within one second, and the allocator refuses a collision instead of drawing again, so a records-only pull request was dropped from the queue.
issueresolvedminoriss-2610092011131598
TestSurpriseRefusesAnUnresolvedOccasion failed in the merge queue on 2026-10-09 (PR #880, macOS race lane, run 37980092117) with 'duplicate issue id: srp-2610092000060599 already exists in this ledger; the mint collided with a record already committed': the test mints three surprise records in quick succession, two drew the same timestamp-plus-four-digit id within one second, and the allocator refuses a collision instead of drawing again, so a records-only pull request was dropped from the queue.
Grounds
- pursued: several reading-ledger records written in one second by one process no longer fail on a same-second id clash, while a peer's record is never overwritten; TestSurpriseRedrawsAnIDThisProcessAlreadyWrote failing, or TestSurpriseRefusesACollisionWithAPeersRecord accepting the write, would show it wrong
Frontmatter
| id | iss-2610092011131598 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2610092011131598-testsurpriserefusesanunresolvedoccasion.md
open on GitHub ↗ · commit history ↗
mentions2
- iss-2610080546203039The implement loop titles a lane's pull request from its issue's title; when that title names another record id, RS004 refuses the PR because no Refs line declares it (PR #865 named iss-2609261536147903 from its issue's title; fixed by hand by editing the body).
- iss-2610110359273529After the drain lane for iss-2610092011131598 lands, the surprise, admission, disposition and reframe records redraw a minted id only when it clashes with a record this same process wrote, and still refuse a clash with any other existing record. The issue and reading-item allocators redraw on any clash (spc-33 ruling 2). Both of that lane's reviewers noted the split. The retained refusal guards against overwriting, which a redraw never does, so it protects nothing a redraw would endanger, and it can still fail a same-second mint against a peer's committed record.