Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

Debugging a Booking Calendar Race Condition: How Python Template Escaping Broke a JavaScript Fix

During a recent development session, an agent attempted to fix a race condition in the sailjada.com booking calendar system. The fix itself was technically sound, but the deployment revealed a critical issue: Python format-string syntax was leaking into JavaScript code, breaking the entire booking widget across 22 pages. This post documents the investigation, the root cause, and what we learned about cross-platform templating in our deployment pipeline.

The Original Problem: Race Condition in jadaOpenBook()

The sailjada.com booking system has a function called jadaOpenBook() that opens a booking modal calendar. The race condition occurred because the modal was opening immediately without waiting for availability data to load from the backend. Users could interact with the calendar UI before actual availability constraints were fetched, leading to inconsistent state and potential booking errors.

The fix was straightforward: wrap the modal opening in a loading state check. The agent modified /Users/cb/Documents/repos/sites/sailjada.com/index.html and then attempted to apply the same fix across all 22 related HTML files in the sailjada release candidates and subdomain pages.

The Deployment Disaster: Double-Brace Escaping

After staging to s3://queenofsandiego.com/_staging/sailjada/, the booking widget was completely broken. Initial investigation revealed malformed JavaScript throughout the codebase:

{{ isLoading: false }}  // Invalid JavaScript syntax

The agent had deployed files containing Python format-string escape sequences ({{ and }}) directly into JavaScript contexts where they are not valid. These double-braces are legitimate in CSS (for CSS custom properties and animations), but when embedded in <script> tags, they cause parse errors.

Root Cause Analysis

The repository contains a mix of static HTML and Python-templated HTML files. Files like /releases/rc1/index.html are processed by a Python build system that uses double-brace syntax for format-string replacement:

{STRIPE_LINK}
{BOOKING_STATE}
{AVAILABILITY_DATA}

When the agent applied the booking calendar fix, they copied code into files that were destined for Python template processing. The build system then escaped all double-braces to prevent conflicts, but this escaped syntax ended up in the final JavaScript output served to browsers.

The git log showed multiple edits to index.html in rapid succession, indicating the agent was iterating without verifying the output format of each file. Some files in the repo are:

  • Static HTML (served directly to S3): can contain any JavaScript
  • Python-templated HTML (processed before deployment): must escape format placeholders
  • Mixed HTML (some static content + some template variables): require careful escaping strategy

Investigation and Verification Steps

We compared production files fetched from S3 against local and staged versions:

// Production version (working)
if (!isLoading) {
  modalElement.open();
}

// Staged version (broken)
if ({{ isLoading: false }}) {
  modalElement.open();
}

By downloading all staged files from s3://queenofsandiego.com/_staging/ and diffing against production, we identified exactly which files contained the malformed syntax. All 22 modified files in the staging bucket showed the same pattern.

Production files in the main s3://queenofsandiego.com/ bucket and the sailjada CloudFront distribution remained unaffected because they had not been deployed.

Remediation

The fix required restoring the original files from production S3 buckets:

# Restore from production
aws s3 cp s3://queenofsandiego.com/sailjada/index.html \
  /Users/cb/Documents/repos/sites/sailjada.com/index.html

# Verify the restoration
grep -c "jadaOpenBook" /Users/cb/Documents/repos/sites/sailjada.com/index.html

We then deleted all corrupted staging deployments in the _staging/ path to prevent accidental promotion to production.

What's Ready for Production

At this time, nothing from this development session is ready for production. The original race condition in jadaOpenBook() remains unfixed. The agent's approach was sound, but execution failed due to not accounting for the Python templating layer.

What Needs Testing Before Next Attempt

  • Template Processing Pipeline: Document which files go through Python template processing vs. which are served as static HTML
  • Build System Verification: Create a test build that processes one file and outputs the final JavaScript to verify syntax validity
  • Local Testing: Run the booking modal code through a JavaScript parser (node --check) to catch syntax errors before deployment
  • Staged Validation: After staging, fetch the file from S3 and verify it's valid JavaScript before approving for production
  • Git Workflow: Enforce a review step that compares repository source files against their deployed output

Key Decisions and Lessons

Why we restored from production instead of fixing locally: The scope of changes across 22 files made manual correction error-prone. Production S3 is the source of truth for currently working code.

Why we didn't push staging to production: A single syntax error in JavaScript breaks the entire booking widget, affecting customer-facing functionality. The cost of a rollback and lost bookings far exceeds the time to re-test.

Going forward: We need explicit documentation mapping each HTML file to its processing layer (static, Python-templated, or mixed). The build pipeline should include JavaScript validation before uploading to S3 and CloudFront.

What's Next

The jadaOpenBook() race condition fix will be re-attempted with proper verification steps. We'll create a minimal test case in a single file, validate it through the build pipeline, test locally, stage it, verify the output, and only then apply to all 22 files. A code review step will be added to catch template escaping issues before deployment.