← Queen of San Diego — Tech Blog

When a Concert Calendar Lies: Reconciling a Venue Schedule Across Two Sites

Yesterday started with a small embarrassment: someone pointed out that the concert series page on both of our sites was missing a show happening that very night. The page had been hand-curated at the start of the season and quietly rotted. This is the story of fixing that, plus the rest of a busy ops day.

The bug: a hand-maintained list drifts

Two static sites, hosted on S3 behind CloudFront, each carried its own copy of a "concert series" page listing waterfront amphitheater shows worth pairing with an evening sail. Nobody owned the sync. A headliner added mid-season never made it onto either page, and the shows were "live" events, the ones we actually want to sell around, rather than film screenings.

The ask was to pull the real published schedule, keep only the live performances for the remainder of the season, and update both sites. Better still: put something in place so it doesn't rot again.

What got built

• A single source of truth. One JSON file of events (date, title, type, ticket link) instead of two hand-edited HTML tables.
• A deterministic renderer. A small Python script reads the JSON, filters out past dates and non-live event types, and emits the same HTML block for both sites. No model in the loop at render time, so the output is reproducible and diffable.
• A deploy step. Sync to each bucket, then invalidate only the concert page path in CloudFront rather than the whole distribution.
• A freshness check. A scheduled launchd job re-fetches the venue schedule, diffs it against our JSON, and flags additions. It drafts a note rather than pushing changes on its own.

events.json  -->  render_concerts.py  -->  concerts.html (site A)
                                      \->  concerts.html (site B)
launchd (daily) --> fetch schedule --> diff --> draft alert

Filtering is where the bugs hide

The venue's calendar mixes live concerts with movie nights and special events. The first pass of the filter matched on a keyword in the title, which is exactly the sort of thing that works until it doesn't. A tribute night with "film" in the name got dropped; a screening with a musician's name got kept. We switched to filtering on the event category field and kept an explicit override list for the odd ones, with the overrides logged so a human can see why something was included.

The rest of the day

Most of the day was the usual operational churn, handled by unattended runs kicked off from a phone:

• A batch of proposal-status checks across several open inquiries, summarized into one digest.
• Reconciling a day's worth of text-message traffic and notes against our records, then updating the affected bookings. A customer asked to move their date to the weekend, so that meant checking crew and vessel availability for both days before proposing anything.
• Sending the concert calendar to a partner after a phone call. Anything client-facing goes into a drafts folder first; a human presses send. That rule held even when the requester was clearly in a hurry.
• A post-charter follow-up run: thank-yous and review requests selected by script, queued as drafts, never auto-sent.

Small snag: auth expiry

The session opened with a forced re-login. Long-running background agents don't fail loudly when credentials lapse. They just stall, so we now check auth state at the top of any unattended run and bail with a clear message rather than half-completing.

The lesson

Any list you maintain by hand in two places will eventually disagree with reality and with itself. The fix isn't more diligence; it's one data file, one deterministic renderer, and a scheduled diff that tells you when the world changed. Let the model do the one-off research and the drafting. Let boring code do everything that has to be right every single day.