Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Debugging a Staging Deployment Gone Wrong: Race Condition Fix Mixed with Template Syntax Errors

What Happened

During a routine booking calendar race condition fix on sailjada.com, a 4.5 agent deployed changes to staging that contained a critical mix of legitimate code updates alongside Python format-string syntax errors. The issue: 22 HTML files across the sailjada subdomain were modified to fix a jadaOpenBook() race condition, but the deployment introduced invalid JavaScript containing unescaped double-braces ({{ }}) that conflict with Python's template syntax.

The root cause: the agent applied a fix across 22 pages without verifying that the production baseline was already using proper Python templating (with placeholders like {STRIPE_LINK}). When the fix was deployed to staging at s3://queenofsandiego.com/_staging/sailjada/, it exposed a mismatch between the local development files and production templates.

The Race Condition: Original Problem

The sailjada booking system had a timing vulnerability: jadaOpenBook() opened the calendar modal immediately without waiting for availability data to load from the backend. This allowed users to interact with an unpopulated calendar, creating a poor UX and potential data inconsistency.

The fix introduced a state-management pattern using jadaBookingState to gate modal opening until availability was fetched. However, in implementing this across 22 files, the agent didn't account for the fact that production files are Python-templated with format-string placeholders.

Technical Details: Template Syntax Collision

Production files in the S3 bucket s3://queenofsandiego.com/ use Python's format-string syntax for configuration injection:

<script>
const STRIPE_LINK = "{STRIPE_LINK}";
const CONFIG = {BOOKING_CONFIG};
</script>

When the agent applied the race condition fix locally and then deployed to staging, they unknowingly introduced this pattern in JavaScript:

jadaBookingState = {{ isLoading: false, calendarReady: false }};

The double-braces {{ }} are intended as JavaScript object notation, but they conflict with Python template parsing. The production baseline uses {{ }} primarily in CSS (for media query fallbacks and grid templates), which is fine, but injecting it into JavaScript creates ambiguity during the template rendering pipeline.

What's in Staging vs. Production

Production state (s3://queenofsandiego.com/):

  • 23 sailjada HTML files with the original jadaOpenBook() implementation (no race condition fix)
  • Python format-string placeholders intact: {STRIPE_LINK}, {BOOKING_CONFIG}
  • CSS double-braces present in media queries and grid definitions
  • No jadaBookingState references

Staging state (s3://queenofsandiego.com/_staging/):

  • 22 sailjada HTML files with jadaOpenBook() race condition fix applied
  • Python format-string placeholders still present
  • New JavaScript containing unescaped double-braces: {{ isLoading: false }}
  • All 22 files modified; metadata shows recent deployment

QoS subdomain files also staged: The brandicarlile.html and other Queen of San Diego index.html updates were staged alongside sailjada changes, but these appear to be unrelated CSS/layout updates (no template syntax conflicts detected).

The Diff: Specific Changes in Staging

A comparison between production index.html and the staged version reveals:

  • Additions: ~45 lines of new JavaScript for jadaBookingState initialization and modal gating logic
  • Removals: None to the core modal trigger, but the immediate call was refactored
  • Syntax errors: Lines containing {{ isLoading: false }} and similar state object definitions
  • Unchanged: Python placeholders ({STRIPE_LINK}), event tracking (gtag calls), CSS double-braces

Why This Matters: Template Rendering Pipeline

The deployment pipeline for queenofsandiego.com works like this:

  1. Source files in S3 are Python-templated (likely processed by a build step or Lambda function)
  2. CloudFront distribution (d[HASH].cloudfront.net mapped to queenofsandiego.com) caches rendered HTML
  3. Template variables are replaced before caching
  4. If double-braces in JavaScript aren't escaped, the template parser may attempt to interpret them as variables

The production files already handle CSS double-braces correctly because they exist in <style> blocks, which the templating engine doesn't parse. But raw JavaScript double-braces in <script> blocks create parsing ambiguity.

What Needs to Happen Next

Immediate action (before promoting to production):

  • Restore the 22 sailjada HTML files from production S3 (confirmed via git log and S3 metadata)
  • Re-apply the race condition fix using proper template escaping: replace {{ }} with escaped braces or use a different state syntax
  • Verify the fix against production's Python template syntax by running a dry-run render
  • Test the booking flow end-to-end in staging to confirm race condition is resolved without syntax errors
  • Update CloudFront cache invalidation after deployment: /* pattern for full invalidation

QoS files (brandicarlile.html and index.html updates):

  • These appear syntactically clean (no template conflicts detected)
  • CSS-only changes, no JavaScript additions
  • Can be promoted separately if testing is complete

Key Decisions & Lessons

Why the fix failed: The agent didn't compare local changes against the production baseline before deploying. Production uses Python templating; local development may not have enforced this constraint.

Deployment strategy going forward: Always diff staged files against production before promotion. Use a pre-flight template validation step that parses both Python placeholders and JavaScript syntax in the same pass.

Naming consistency: The jadaBookingState variable introduced in the fix is sound from a UX perspective (gates modal until availability loads), but its implementation via double-braces wasn't template-aware.

Summary

The race condition fix is conceptually correct but syntactically incompatible with the production templating pipeline. The staging deployment is not ready for production. Restore the 22 files, re-apply the fix with escaped or alternative syntax, and re-test before promoting. The QoS updates appear safe to proceed independently.