fix(tickets): allocate ticket IDs atomically - #631
Conversation
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe change adds atomic ticket ID reservation through ChangesTicket ID allocation
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant ticketWorkflow
participant reserveTicketId
participant app.db
participant Discord
participant ticketsTable
ticketWorkflow->>reserveTicketId: reserve ticket ID
reserveTicketId->>app.db: atomically update ticketIdSequence
app.db-->>reserveTicketId: return reserved ID
reserveTicketId-->>ticketWorkflow: return numeric ticket ID
ticketWorkflow->>Discord: create resources with rendered ticket number
ticketWorkflow->>ticketsTable: persist reserved ID as primary key
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
COUNT(tickets) + 1with an atomic SQLite-backed ID reservation.Implementation
The allocator stores its sequence in the existing
app_metatable. A single upsert catches up with existing ticket records and serializes concurrent reservations before any Discord resources are created.A failed Discord operation may consume an ID and leave a gap. Reserved IDs are intentionally never reused, preserving uniqueness.
Summary by CodeRabbit
New Features
Bug Fixes