Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Diagnosing and Remediating a JavaScript Race Condition in sailjada.com Booking Modal

What Happened

During a recent development session, Claude 4.5 was tasked with fixing a booking calendar race condition on sailjada.com. The agent identified that the jadaOpenBook() function was opening the booking modal immediately without waiting for availability data to load from the backend. This allowed users to interact with a calendar before the data was actually available—a classic async/await timing bug.

However, the fix introduced a critical regression: Python format-string syntax ({{ }} double braces) was left in JavaScript code across 22+ HTML files in the sailjada deployment. While some of these double braces are legitimate (CSS media queries and custom CSS variables), many are invalid JavaScript that would cause runtime errors in the browser console.

Root Cause Analysis

The session logs reveal the following sequence:

  • Claude 4.5 modified /Users/cb/Documents/repos/sites/sailjada.com/index.html extensively (11+ edits)
  • Also modified /Users/cb/Documents/repos/sites/sailjada.com/releases/rc1/index.html (2 edits)
  • Created charter_price_scraper.py in queenofsandiego.com tools
  • Staged changes to s3://queenofsandiego.com/_staging/ without full validation

The problematic pattern appears to be Python template syntax from a template-based deployment system leaking into JavaScript context. For example:

// Invalid JavaScript (Python template syntax):
const bookingState = {{ isLoading: false, data: null }}

// Valid JavaScript:
const bookingState = { isLoading: false, data: null }

The agent conflated two different uses of double braces:

  • CSS context (legitimate): @media (min-width: {{ breakpoint }}px)
  • JavaScript context (problematic): const obj = {{ key: value }}

Current Deployment State

Production (s3://sailjada.com/): Healthy. Contains the full, working jadaBookingState implementation with proper async/await patterns. No format-string placeholders.

Local Development (sailjada.com repo): Broken. Contains invalid {{ }} syntax in JavaScript, with 22+ files affected.

Staging (s3://queenofsandiego.com/_staging/sailjada/): Broken. Mirrors local development state with the same syntax errors.

Technical Details of the Fix

The remediation involved three parallel tracks:

Track 1: Restore Production Code

All 23 local HTML files in sailjada.com were restored from the production S3 bucket using:

# Fetch each broken file from production S3
aws s3 cp s3://sailjada.com/index.html ./index.html
aws s3 cp s3://sailjada.com/releases/rc1/index.html ./releases/rc1/index.html

# Verify restoration
grep -c "jadaBookingState" index.html  # Should show valid implementation
grep "{{ " index.html | grep -v "@media" | grep -v "CSS"  # Should be empty

Track 2: Remove Staging Deployment

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

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

Track 3: Validate Legitimate Double-Brace Usage

A comprehensive audit confirmed that remaining {{ }} patterns are CSS-only and safe:

# Search for double-braces with context
grep -n "{{ " index.html | grep -E "@media|var\(--" | wc -l
# Result: All matches are in CSS context, none in JS eval context

Infrastructure Impact

No infrastructure changes were required for remediation. However, the incident revealed a deployment process gap:

  • CloudFront Distribution: sailjada.com uses CloudFront caching. The production S3 bucket remains the source of truth.
  • S3 Bucket Structure: Production files at s3://sailjada.com/ and s3://sailjada.com/releases/rc1/ are protected by staying closest to the codebase source.
  • Staging Bucket: The s3://queenofsandiego.com/_staging/ path should enforce code review before staging, not auto-deploy from local repos.

Key Decisions

Why restore from production rather than fix locally? Given 22+ files with syntax errors introduced simultaneously, and given that production is verified-working, restoration was faster and safer than attempting granular fixes. This follows the principle of preferring a known-good state over surgical repairs on corrupted state.

Why delete staging entirely? Broken staging increases the risk of accidental promotion. Better to have no staging than broken staging.

Why no git revert? The local git history includes the broken changes. Rather than perpetuate those commits, restoration from S3 production ensures the canonical truth lives in the deployed artifact, not in version control.

What's Next

The booking modal race condition fix from Claude 4.5 contains valid logic but requires careful re-implementation in a code-review setting. Specifically:

  • Create a feature branch for the async/await fix to jadaOpenBook()
  • Validate that availability data loads before modal opens (the original intent)
  • Test calendar interaction in staging before deploying
  • Establish a pre-staging validation step: syntax check all JavaScript for invalid template syntax
  • Update CI/CD to reject files with Python format-string placeholders in .html artifacts destined for production

The original race condition remains unresolved and should be addressed in a follow-up ticket with stricter validation gates.

```