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 were invisible on the dashboard. The fix: two PRs surfacing donations in the top-level stats and including the payment method in revenue aggregation.
QR code scan processing updated three tables: tickets, scan_logs, and qr_validations— none wrapped in a transaction. A crash between writes left partial state, allowing double-entry at the door. The fix 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 surfaced as unnamed attendees at check-in. Explicit boundary validation at the API layer — before any write — closed the gap.
getEventStatistics() included complimentary (free) tickets in the revenue-per-attendee denominator, deflating the figure. The fix excluded comp tickets from revenue aggregation so statistics reflect paying attendees only.
Execution Approach
Each bug was independent — no shared root cause. The right approach was parallel: 7 targeted PRs, each fixing one specific behavior with its own test. This minimized merge conflict risk and let CI verify each fix in isolation.
- ›Audit-first: ran a full Turso prod snapshot before any fixes shipped — establishing source-of-truth figures to verify against post-merge.
- ›Parallel PRs, independent branches: each of the 7 PRs targeted a single function or API endpoint with no file overlap. No merge conflicts on the critical path.
- ›Regression pins: a defensive test pinning the
countSqlplaceholder ↔ args invariant locked the fix in place against future regressions. - ›Prod verification protocol: after all 7 PRs merged, post-merge verification diffed live API figures against the Turso snapshot — zero discrepancies.
Quantified Results
17 required checks passed across all 7 PRs — zero rollbacks, zero hotfixes after merge.
QR scan writes wrapped in a transaction for the first time. Double-entry at check-in physically impossible.
All four revenue/attendance aggregation bugs fixed before D presented event financials to the nonprofit.
Event-day monitoring runbook documented failure modes. 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 certainty for a non-repeatable live event.
- ›Parallel PRs over a single omnibus fix. Seven targeted PRs — each independently reviewable, testable, and reversible — outperformed one large PR in every dimension that mattered at deadline.
- ›Establish the baseline before shipping fixes. A Turso prod snapshot gave a concrete target to verify against. Without it, “the numbers look right” is judgment, not verification.
- ›Boundary validation is the last line of defense. The null attendee bug passed through frontend, API handler, and service layer because none treated a missing name as an error. Explicit validation at the API boundary is the only reliable guarantee.