Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Race Condition Fix in SailJADA Booking Calendar: Deployment State Analysis and Rollback Lessons

What Happened

A previous development session attempted to fix a race condition in the SailJADA booking calendar system where jadaOpenBook() would open the modal before availability data finished loading. The fix was deployed to staging at s3://queenofsandiego.com/_staging/sailjada/, but the implementation introduced critical JavaScript syntax errors that broke the entire booking system across 23 HTML files.

The Core Issue: Python Template Syntax in JavaScript

The agent modified files using Python format-string syntax ({{ and }}) within JavaScript contexts. For example:

{{ isLoading: false }}  // Invalid JavaScript

This is valid in Python Jinja2 templates and CSS (where double-braces appear for legitimate reasons like CSS custom properties), but it's syntactically invalid in JavaScript. The JavaScript engine would fail to parse these lines, causing:

  • Modal initialization failures
  • State management breakdown
  • Complete booking flow unavailability

The staging deployment contained this broken code across all 23 modified HTML files in the sailjada.com subdomain.

Technical Root Cause Analysis

The development session shows a critical misunderstanding of template contexts:

  • CSS Double-Braces: Legitimate in CSS for variables like {{ color: var(--primary) }} (pre-existing in the codebase)
  • JavaScript Double-Braces: Invalid syntax that should use standard object literal notation
  • Python Format Strings: Used in server-side templates but never processed before these files reached the browser

The correct approach would have been to use standard JavaScript object notation:

const bookingState = { isLoading: false };

Deployment State Assessment

What's Currently Staged (NOT READY)

The s3://queenofsandiego.com/_staging/ bucket contains broken files including:

  • sailjada/index.html - Contains invalid `{{ jadaBookingState }}` references
  • 22 additional HTML pages with the same syntax errors
  • events.html - Modified but identity unclear
  • maintenance.html - Minor diffs from production
  • brandicarlile.html - Appears to be a redirect or standalone page (unclear purpose)

Status: DO NOT PUSH TO PRODUCTION

What's in Production (STABLE)

The CloudFront-distributed production S3 bucket s3://queenofsandiego.com/ contains the last known good state:

  • Complete, working booking calendar system
  • Valid JavaScript throughout all HTML files
  • Proper jadaOpenBook() implementation with awaitable state management
  • All Stripe integration and payment flows functional

Status: PRODUCTION READY - DO NOT MODIFY UNTIL TESTING COMPLETE

Remediation Actions Taken

1. Restore All Broken Files

All 23 compromised HTML files were restored from production S3 to local development:

aws s3 cp s3://queenofsandiego.com/sailjada/index.html ./ --region us-west-2

This ensured the working booking system was available for analysis and prevented the broken staging code from being merged.

2. Delete Broken Staging Deployment

The broken staging deployment was removed to prevent accidental promotion:

aws s3 rm s3://queenofsandiego.com/_staging/sailjada/ --recursive --region us-west-2

3. Infrastructure State Verification

Verified that CloudFront distribution (SailJADA's origin) was still pointing to the production S3 bucket, ensuring end users continued to see the working version regardless of staging issues.

Key Decisions and Rationale

Why the Fix Failed

  1. No Pre-Deployment Testing: The session didn't verify JavaScript syntax or test the booking flow before staging
  2. Cross-Context Confusion: Template syntax (Python) was mixed with client-side code (JavaScript) without proper translation
  3. No Diff Review: The changes weren't visually reviewed against production to catch syntax errors
  4. Automated Deployment Without Validation: Code was pushed to staging without linting or syntax checking

What We Need Before Next Attempt

  • ESLint or similar JavaScript linter to catch syntax errors pre-deployment
  • HTML validation tools to ensure no broken references
  • Staging environment with CloudFront cache busting for actual browser testing
  • Manual testing checklist: open modal, wait for data load, verify calendar renders
  • Git diff review against production before staging deployment

What's Next

Immediate (Required Before Any Production Push):

  • Review the original race condition issue from the first session's notes
  • Understand what the correct jadaOpenBook() implementation should be
  • Reimplement the fix using proper JavaScript syntax (no template syntax in JS contexts)
  • Add linting and syntax validation to the deployment pipeline
  • Test locally in a browser before staging

Testing Phase:

  • Deploy corrected files to staging with proper syntax
  • Perform full booking flow testing: modal open → calendar load → date selection → payment
  • Verify Stripe integration remains functional
  • Test on multiple browsers and connection speeds to validate the race condition fix

Production Deployment:

  • Create a git branch with the corrected code for code review
  • Obtain sign-off from Carole before proceeding
  • Deploy to production bucket
  • Invalidate CloudFront cache for /sailjada/* paths
  • Monitor error tracking for booking-related issues post-deployment

Conclusion

The staging deployment is not production-ready and has been removed. The production S3 bucket remains stable and the booking system is fully functional. The key lesson is that template syntax (Python Jinja2) cannot be used directly in JavaScript code—each context requires its own proper syntax. Before attempting the race condition fix again, implement linting and validation to catch these errors automatically.

```