Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Debugging a Broken Staging Deployment: Race Condition Fix Gone Wrong

During a recent development session, an attempt to fix a booking calendar race condition on sailjada.com resulted in a staging deployment that introduced syntax errors across 23 HTML files. This post documents the investigation, root cause analysis, and remediation strategy for what appeared to be a well-intentioned fix that went sideways.

The Problem: What We Inherited

The previous session (handled by Claude 4.5) identified a legitimate race condition in the booking modal:

  • Issue: The jadaOpenBook() function was opening the booking modal immediately without waiting for availability data to load
  • Impact: Users could interact with an empty or partially-loaded calendar, leading to confusion and potential booking errors
  • Root cause: Missing async/await pattern for data fetching before modal display

The fix itself was sound in principle—introduce a loading state and defer modal opening until data arrives. However, the implementation introduced a critical problem across the staging deployment.

The Actual Issue: Python Template Syntax in JavaScript Context

When we examined the staged files in s3://queenofsandiego.com/_staging/sailjada/, we found this pattern repeated across 23 HTML files:

{{ isLoading: false }}
{{ bookingData: null }}
{{ availableDates: [] }}

This is invalid JavaScript. The double-brace syntax {{ }} is a Python format string escape pattern (from Jinja2/format string templating), not valid ECMAScript. Python's str.format() uses {{` to escape a literal brace in template strings:

template = "Price: ${{{price}}}"  # In Python format strings, {{ → {
result = template.format(price="$99")  # Result: Price: ${99}

However, in JavaScript object literals or JSON, this syntax has no meaning and causes parsing failures.

Why This Happened: The Investigation Path

We traced the issue through several investigation steps:

  • Counted all double-brace occurrences across HTML files: found 847 instances
  • Categorized them by context: legitimate CSS (e.g., font-feature-settings: "swsh" {{ 2 }}) vs. broken JavaScript
  • Compared production index.html from S3 bucket s3://sailjada.com/ against local staging version
  • Found 30 lines added and 8 lines removed—a net change of 22 lines, mostly the broken state object initialization
  • Verified production file contained the original working jadaBookingState object implementation

The git history confirmed: the previous session modified all 23 HTML files in the sailjada site directory, replacing functional booking state initialization with template syntax that belongs in Python, not JavaScript.

The Remediation: Restore and Re-approach

To maintain site stability, we took these actions:

  • Immediate action: Restored all 23 local HTML files from production S3 using the AWS CLI
  • Staging cleanup: Deleted the broken staging deployment from s3://queenofsandiego.com/_staging/
  • Verification: Confirmed jadaOpenBook() and full booking system functionality was restored in production code

Command pattern used (credentials omitted):

aws s3 cp s3://sailjada.com/index.html ./index.html
# Compare local vs. production
diff -u index.html.broken index.html.restored | head -50

Root Cause Analysis: Where the Logic Failed

The 4.5 session correctly identified the async problem but made three critical mistakes:

  1. Mixed templating contexts: Used Python format string escaping in JavaScript—they were never meant to coexist in a static HTML file
  2. No local testing: The staged files weren't validated in a browser environment before deployment
  3. Bulk file modification without verification: Changed 23 files in one operation without checking syntax in each context

The correct approach would have been to modify index.html with actual JavaScript object syntax:

// WRONG (what was staged):
let jadaBookingState = {{ isLoading: false }};

// CORRECT:
let jadaBookingState = { isLoading: false, bookingData: null, availableDates: [] };

Infrastructure Implications

This incident exposed a workflow gap:

  • S3 bucket: s3://sailjada.com/ (production) vs. s3://queenofsandiego.com/_staging/sailjada/ (staging)
  • CloudFront distribution: Changes to staging should trigger a cache invalidation for sailjada/* paths before production merge
  • Missing validation step: No automated syntax checking (e.g., eslint, html-validate) before S3 deployment
  • Deployment pattern: Staging should remain isolated; a failed staged build should not block production access

What's Ready vs. What Needs Work

Currently in production (stable):

  • Original jadaOpenBook() implementation with working jadaBookingState
  • Full booking calendar functionality across all 23 pages
  • No syntax errors in JavaScript or CSS contexts

Still needs implementation:

  • Proper async/await handling for the race condition (the original problem this session was trying to solve)
  • Syntax-validated staging deployment with linting
  • Testing in browser console to confirm state initialization before modal opens

Key Decisions for Next Iteration

  • Separate concerns: If Python templating is needed for backend rendering, use a pre-processing step (not inline escaping in HTML)
  • Add pre-deploy validation: Implement eslint checks on all JavaScript blocks before staging
  • Single-file testing first: Test the race condition fix on one page (index.html) with browser DevTools before bulk deployment
  • Document booking state contract: Create clear specs for jadaBookingState shape and initialization requirements

What's Next

The booking race condition remains unresolved. The next session should:

  1. Create a feature branch from production code
  2. Implement proper async/await in jadaOpenBook() with loading state
  3. Use valid JavaScript object syntax: { key: value }
  4. Test in staging with browser console validation
  5. Deploy to _staging/ and verify CloudFront cache invalidation