Public: anyone can read this; the crew can change it.
An accepted report keeps its issue's number even when labelling fails #774
Check · Review · Land · Live done — Landed and live in production.
Closes #771
shipped production is serving it for issue #771 — its issue is already done deploy 7cfd21c
Sign in to join this conversation.
new above
offline
Closes #771
What changes.
acceptReportopened the issue, labelled it, and only then noted the number on the report and told the outbox. If labelling threw, the issue existed while the report stayed accepted with no number and no event: in no queue, and refused if accepted again. The number and the event now come first, as soon as the issue has opened.A database transaction around the whole acceptance is not possible: on a mirror the issue is opened at the origin, across an await. Recording first gives the same guarantee where it matters: once an issue exists, the report knows it.
Test (
test/reports.test.ts, 25, one new). A trigger makes the label write fail after the issue has opened. The report is accepted with its number; the issue is there asFrom outside: …;report.acceptedis in the outbox once; the report no longer waits; a second accept is refused asdecidedand opens no second issue. Against the old order the test fails on the missing number.Unchanged. A labelling failure still throws: it means the forge is broken, and the title's marker, which the brief also reads, is already on the issue.
Verified. tsc clean; reports, report-discovery, reserved-names, studio, check-list and hollow, 248/248 in one run on main b36233a;
bun scripts/hollow.tsclean.🤖 Generated with Claude Code