Case Study
A Lo Cubano Boulder Fest
A production ticketing platform serving a live Latin dance event — and the three critical bugs I found and fixed in the weeks before May 15 go-live: an analytics undercount, a QR validation race condition, and a silent data corruption in checkout.
Context
A Lo Cubano Boulder Fest is a Latin dance festival I built from scratch — full ticketing, payment processing, QR-code check-in, and an admin analytics dashboard. The stack is Node.js, Vercel, Stripe, and Turso (LibSQL edge database).
Three weeks before the May 15 event, a systematic audit of the analytics dashboard surfaced four distinct data correctness bugs. Each was independent in cause but convergent in effect: every revenue and attendance figure shown to the event organizer was wrong.
The Bugs
The admin dashboard /api/admin/dashboard stats query omitted manual_entry donation rows from its transaction_stats CTE. Pure-donation transactions — those not tied to a ticket purchase — were invisible on the dashboard. The fix: two PRs (#464, #467) — the first surfacing donations in the top-level stats, the second fixing the CTE to include the manual_entry payment method in the revenue aggregation.
QR code scan processing updated three tables: tickets, scan_logs, and qr_validations. None of these writes were wrapped in a transaction. A crash between any two writes left the database in a partial state — a ticket could be marked used in scan_logs but not in tickets, allowing double-entry at the door. PR #465 wrapped the full scan sequence in a LibSQL transaction with rollback on any failure.
The checkout API accepted attendee payloads with missing firstName / lastName fields, silently storing null in the database. These records surfaced as unnamed attendees on the check-in dashboard, requiring manual lookup by ticket number at the door. PR #466 added explicit boundary validation rejecting partial attendee payloads before they reach the database.
getEventStatistics() in the analytics service computed average revenue per attendee by including comp (complimentary) tickets in the denominator while summing their $0 value — deflating the per-attendee revenue figure. PR #469 excluded comp tickets from the revenue aggregation so that statistics reflect paying attendees only.
Execution Approach
Each bug was independent — no shared root cause, no fix that would solve two at once. The right approach was parallel: 7 targeted PRs, each fixing one specific behavior, each with its own test. This minimized merge conflict risk and let CI verify each fix in isolation before any hit production.
- ›Audit-first: ran a full Turso prod snapshot before any fixes shipped, establishing source-of-truth figures for donations, revenue, and attendance counts. This gave a baseline to verify the fixes against post-merge.
- ›Parallel PRs, independent branches: each of the 7 PRs targeted a single function or API endpoint. No PR touched the same file as another — no merge conflicts on the critical path.
- ›Regression pins: PR #470 added a defensive test pinning the
countSqlplaceholder ↔ args invariant — an audit-rebuttal that locked the fix in place and prevented future regressions. - ›Prod verification protocol: after all 7 PRs merged, a post-merge verification would diff the live API figures against the Turso snapshot — zero discrepancies expected. Any gap would surface as a P1 follow-up before the event.
Quantified Results
17 required checks passed across all 7 PRs — zero rollbacks, zero hotfixes needed after merge.
QR scan writes wrapped in a transaction for the first time. Double-entry at check-in physically impossible after PR #465.
All four revenue/attendance aggregation bugs fixed before D presented event financials to the nonprofit. No manual correction needed.
Event-day monitoring runbook documented failure modes and recovery steps. Organizer had a single source of truth for attendee counts and revenue.
Tech Stack
Lessons
- ›Deadline pressure exposes assumptions. The atomicity bug had been in the codebase since launch. It only became urgent when we needed to be certain the door check-in system was reliable for a non-repeatable live event. Auditing under deadline is not ideal — but it is revealing.
- ›Parallel PRs over a single omnibus fix. One PR touching 4 bugs would have been faster to open and harder to review, harder to revert, and harder to verify. Seven targeted PRs meant each fix was independently reviewable, independently testable, and independently reversible if any one broke something unexpected.
- ›Establish the baseline before shipping fixes. Taking a Turso prod snapshot first gave a concrete target to verify against after merge. Without it, “the numbers look right” is judgment, not verification.
- ›Boundary validation is the last line of defense. The null attendee bug passed through multiple layers before reaching the database — frontend form, API handler, service layer — because none of them treated a missing name as an error. Explicit validation at the API boundary, before any write, is the only reliable guarantee.