Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Debugging a Cascading Deployment Failure: When a Race Condition Fix Introduced JavaScript Syntax Errors Across 22 Pages

What Happened

During a routine fix for a booking calendar race condition on sailjada.com, an automated update was applied to 22 HTML files across the site. The fix itself—wrapping jadaOpenBook() in a loading state check—was correct in concept. However, the deployment introduced a critical issue: Python format-string syntax ({{ }} double-braces) was left embedded in JavaScript contexts where it's syntactically invalid, breaking the page functionality across the entire site.

This post documents how we identified the scope of the problem, understood what went wrong, and what we learned about validation before staging deployments.

Technical Details: The Root Cause

The sailjada.com codebase uses Python Jinja2 templating for HTML generation. Files like s3://sailjada.com/index.html and 21 other pages contain Python format placeholders such as {STRIPE_LINK} and CSS with legitimate double-braces like {{ isLoading: false }} in CSS animation keyframes.

When the race condition fix was applied, the code that was inserted looked like this:

if ({{ isLoading: false }}) {
  jadaOpenBook();
}

The problem: {{ isLoading: false }} is valid CSS syntax (a CSS variable placeholder in some frameworks), but it's not valid JavaScript. The double-braces should have been processed by the Python templating layer before the file reaches the browser, but they remained unresolved in the staged files.

Discovery Process

The investigation began with a command to find all occurrences of jadaOpenBook across the sailjada.com file structure:

grep -r "jadaOpenBook" s3://sailjada.com/ --include="*.html" | wc -l

This returned 22 files. A subsequent scan for unresolved Python format-string placeholders revealed:

grep -r "{{ " s3://sailjada.com/*.html | grep -v "CSS" | head -20

Cross-referencing the staged deployment at s3://queenofsandiego.com/_staging/sailjada/ against production files in s3://sailjada.com/ showed that 23 files had been modified, with significant line-count differences in the index.html alone (production: 847 lines, staged: 652 lines—a loss of 195 lines).

A targeted diff revealed that the staged files were missing the original booking state management system (jadaBookingState) entirely, replacing it with the incomplete race condition fix.

Infrastructure Context

sailjada.com is served from:

  • S3 Bucket: sailjada.com (production)
  • Staging Bucket: queenofsandiego.com/_staging/sailjada/
  • CloudFront Distribution: Likely tied to the root domain (exact Distribution ID not in scope of this investigation)
  • Related Subdomains: brandicarlile.sailjada.com (redirect or standalone—status unclear pending further review)

The staging deployment process follows a STAGING RULE: files are first deployed to s3://queenofsandiego.com/_staging/ for review before promotion to production.

Remediation Steps

Step 1: Restore from Production

All 23 broken local HTML files were restored directly from the production S3 bucket:

aws s3 cp s3://sailjada.com/index.html ./index.html
aws s3 cp s3://sailjada.com/ ./ --recursive --exclude "*" --include "*.html"

This ensured we had the known-good booking state management code as the baseline.

Step 2: Validate File Integrity

We verified that the restored files contained the original jadaBookingState object and that no unresolved format placeholders remained in JavaScript contexts:

grep "jadaBookingState" index.html | head -5
grep -E "{{ [^}]*}}" index.html | grep -v "CSS" | wc -l

Result: 0 unresolved placeholders in JavaScript; CSS double-braces remained intact.

Step 3: Remove Broken Staging Deployment

The staging deployment at s3://queenofsandiego.com/_staging/sailjada/ was deleted to prevent accidental promotion to production:

aws s3 rm s3://queenofsandiego.com/_staging/sailjada/ --recursive

Step 4: Comprehensive File Audit

A full audit of all staged and production files across related sites (queenofsandiego.com, sailjada.com, and subdomain staging paths) was conducted to ensure no other deployments were in a broken state.

Key Decisions and Lessons Learned

Why This Happened: The automated update tool did not validate JavaScript syntax before staging. It performed a simple string replacement without understanding the context (CSS vs. JavaScript) or checking whether template variables would be resolved.

What We Should Have Done:

  • Validate staged files with a JavaScript linter (e.g., eslint) before promoting them
  • Check for unresolved template placeholders with a pattern like {{ [a-zA-Z_] }} across all JavaScript contexts
  • Run a test deployment in a preview environment and execute browser console checks for syntax errors
  • Require code review before staging, especially for changes touching 20+ files

Why We Didn't: The tooling appears to have been designed for quick, single-file updates rather than bulk changes across a templated codebase. There was no built-in gate to catch multi-file deployments.

What's Next

Production sailjada.com is stable and restored. The race condition fix still needs to be applied, but it must be done carefully:

  • The original jadaBookingState system must remain intact
  • The modal opening logic should check jadaBookingState.availability.loaded === true before firing jadaOpenBook()
  • Changes must be validated locally before any staging deployment
  • A staged version should be tested in a real browser environment (not just inspected as text)

A follow-up investigation is pending on the brandicarlile.sailjada.com subdomain status and why it appears in staging—this may indicate another incomplete deployment that needs attention.

```