Debugging a Booking Calendar Race Condition: How Python Template Syntax Leaked Into JavaScript

Last week, an agent attempted to fix a race condition in the sailjada.com booking calendar where jadaOpenBook() was firing before availability data had loaded. The fix seemed straightforward on the surface—add a loading state check. But when deployed to staging, it revealed a deeper infrastructure issue: Python format-string placeholders were persisting in production HTML files, and a well-intentioned refactor had introduced invalid JavaScript syntax alongside them.

The Root Problem: Format String Escaping in a Multi-Layer Build Pipeline

The sailjada.com infrastructure uses a hybrid deployment model that caught us off-guard:

• Source files: Stored in `/Users/cb/Documents/repos/sites/sailjada.com/` as Python Jinja2 templates with placeholders like {STRIPE_LINK}
• Production deployment: Files uploaded to S3 bucket s3://sailjada-landing-pages/ (served via CloudFront)
• Staging review: Same files pushed to s3://queenofsandiego.com/_staging/sailjada/ before production merge

The agent modified 22 HTML files to fix the race condition but didn't account for the fact that production files still contained unresolved Python format strings. When comparing local edits against production S3, the diff was massive because the production version was the "rendered" HTML (with placeholders already filled in), while local files were still in template form.

Technical Details: The Syntax Collision

Here's where it gets tricky. The agent's fix for jadaOpenBook() looked like this:

<script>
function jadaOpenBook() {
  if ({{ isLoading: false }}) {
    // Open modal
  }
}
</script>

This is invalid JavaScript. Double-brace syntax `{{ }}` is used in:

• CSS (legitimate): @supports (display: {{ css-var }}) { ... } for CSS custom properties
• Python Jinja2 templates (legitimate): {{ variable_name }} for backend variable substitution
• JavaScript (NOT legitimate): `{{ isLoading: false }}` has no meaning in JS—it looks like an object literal missing the const obj = prefix, but the double braces break it

The agent's search for "all double-brace occurrences" conflated CSS double-braces (which should stay) with JavaScript double-braces (which should never exist). This is a parsing context problem.

Infrastructure State: Staged vs. Production

We discovered 23 HTML files with the broken jadaBookingState code staged to s3://queenofsandiego.com/_staging/:

• index.html (sailjada root)
• releases/rc1/index.html
• 20 other booking-related pages

Comparison between staging and production revealed:

• Production files: Contained the full, working jadaOpenBook implementation with proper booking widget integration
• Staged files: Contained the race-condition "fix" that broke the booking system entirely
• Related impact: Staging also included updates to queenofsandiego.com files (likely an accidental bucket pollution), including removal of critical booking confirmation email references from the homepage

Key Decisions and Remediation

Decision 1: Revert the staging deployment entirely. Rather than cherry-pick fixes, we restored all 23 files from production S3 back to staging, ensuring the full booking system and email integration remained intact. The race condition fix needs to be re-architected with proper testing.

Decision 2: Separate template files from rendered files. Going forward:

• Store .jinja2 template versions in Git (with placeholders like {STRIPE_LINK})
• Use a build step (Python or shell script) to render templates before S3 upload
• Never mix local template files with production rendered files in diff comparisons

Decision 3: Validate JavaScript syntax before staging. Add a pre-deploy check:

# Simple validation: ensure no {{ }} in <script> blocks
grep -E '<script[^>]*>.*\{\{.*\}\}.*</script>' *.html || echo "No double-braces in JS blocks"

Current State: What's Ready, What's Not

Ready for production:

• Current production files in s3://sailjada-landing-pages/ (CloudFront CDN active)
• All 23 broken staged files have been reverted to production versions
• The booking system is functional end-to-end

Still in testing / not ready:

• The actual race condition fix for jadaOpenBook()—needs redesign to avoid double-brace syntax issues
• Integration with JADA email ops tooling (balance-due email templates in BookingAutomation.gs and CaroleEmailOps.gs)—requires separate audit
• The staging pollution on queenofsandiego.com/_staging/ files—needs investigation into why QoS booking confirmation references were removed

What's Next

For the proper race condition fix:

1. Use JavaScript state variables instead of template syntax:

   let availabilityLoaded = false;
   function jadaOpenBook() {
     if (availabilityLoaded) {
       // open modal
     }
   }

2. Set `availabilityLoaded = true` only after the availability fetch resolves
3. Test in staging before production merge
4. Audit the queenofsandiego.com staging changes and determine if they should be rolled back or merged intentionally

This incident underscores why separating template rendering from deployment is critical—especially when multiple team members are touching the same infrastructure layer.