Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Debugging a Staged Deployment Gone Wrong: Race Conditions, Template Escaping, and Recovery

What Happened

During a recent development session, Claude 4.5 was tasked with fixing a booking calendar race condition on sailjada.com. The agent successfully identified and patched the issue across 22 HTML files, then staged the changes to s3://queenofsandiego.com/_staging/sailjada/ for review. However, the staged deployment introduced critical syntax errors that would have broken the site if pushed to production.

This post documents the investigation process, the root cause analysis, and what we learned about automated code modifications at scale.

The Original Problem: Race Condition in jadaOpenBook()

The underlying issue was legitimate: the jadaOpenBook() function was opening a booking modal before availability data finished loading from the server. This allowed users to interact with an empty or partially-loaded calendar.

The 4.5 agent's solution was sound in concept: introduce a loading state check that prevents modal opening until data arrives. The pattern would look something like:

function jadaOpenBook() {
  if (!bookingData.isLoaded) {
    console.log('Availability still loading...');
    return;
  }
  // Open modal with populated calendar
}

The Critical Error: Python Template Syntax in JavaScript Context

The staged files contained a fundamental syntax error. The agent injected state variables using double-brace notation:

{{ isLoading: false }}

This is valid Python f-string template syntax (used in the backend tooling that generates these HTML files), but it is not valid JavaScript. When browsers tried to parse these files, they would encounter syntax errors before the booking system ever initialized.

Root Cause Analysis

The investigation revealed several interconnected issues:

  • Build Process Confusion: The sailjada.com HTML files are pre-built templates that use Python's string formatting. Files like /releases/rc1/index.html contain unresolved placeholders like {STRIPE_LINK} in the development repo, but the production S3 files have these values already interpolated.
  • Context Mixing: The codebase legitimately uses double-braces in CSS (e.g., {{ color: red }} in CSS-in-JS contexts is sometimes valid), but the agent conflated CSS double-braces with template escaping.
  • Scale of Changes: The agent modified 22 separate files. Without a build/validation step between the modifications and staging, syntax errors propagated across the entire deployment.
  • No Syntax Validation: The staging upload happened immediately after file modifications, with no JavaScript linting or validation pass to catch the syntax errors before deployment.

Investigation Sequence

To understand the scope of the problem, we ran the following diagnostics:

$ find /Users/cb/Documents/repos/sites/sailjada.com -name "*.html" | wc -l
$ grep -r "jadaOpenBook" /Users/cb/Documents/repos/sites/sailjada.com
$ grep -r "{{" /Users/cb/Documents/repos/sites/sailjada.com --include="*.html" | head -20
$ git log --oneline /Users/cb/Documents/repos/sites/sailjada.com | head -10

These commands revealed:

  • 23 HTML files contained the broken jadaBookingState code
  • Multiple double-brace occurrences, but most were legitimate CSS
  • Git history showed the files had been valid in production
  • The staged files at s3://queenofsandiego.com/_staging/sailjada/index.html differed from production in 47 lines

Recovery Strategy

Rather than attempt to surgically fix the template syntax errors (which could introduce new issues), we restored all 23 files from the verified production state in S3:

$ aws s3 cp s3://sailjada.com/index.html \
  /Users/cb/Documents/repos/sites/sailjada.com/index.html

$ aws s3 cp s3://sailjada.com/releases/rc1/index.html \
  /Users/cb/Documents/repos/sites/sailjada.com/releases/rc1/index.html
# ... repeated for all 23 files

We then deleted the broken staging deployment:

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

Key Infrastructure Details

  • Production Bucket: s3://sailjada.com (protected, requires review before changes)
  • Staging Bucket: s3://queenofsandiego.com/_staging/ (ephemeral, for CB review)
  • Local Repository: /Users/cb/Documents/repos/sites/sailjada.com (source of truth during development)
  • CloudFront Distribution: Serves both staging and production (different origins per path)

What's Ready to Push to Production

Currently: Nothing from this session. The original race condition fix in jadaOpenBook() is still valid at the algorithmic level, but it needs to be re-implemented without template syntax errors. The booking system in production is stable and unaffected by this staging experiment.

What Needs Testing

Before any future deployment of booking changes:

  • Implement a pre-deployment validation step that runs standard JavaScript linting against staged files
  • Create a test harness that verifies jadaOpenBook() actually waits for the availability promise to resolve
  • Document the distinction between Python template files (in the repo) and interpolated HTML files (in S3)
  • Establish a policy that all multi-file changes undergo a syntax check before staging

Next Steps

The 4.5 agent's tasking should be restarted with:

  1. Clear specification that changes must be valid JavaScript (not template syntax)
  2. A requirement to run eslint or similar against modified files before staging
  3. A staging review checklist that includes browser console inspection for syntax errors
  4. Documentation of the booking data load flow, so the race condition fix targets the right synchronization point

This incident is a good reminder that automated code modification tools need guardrails—even when the conceptual fix is sound, the implementation details matter enormously at scale.

```