Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Debugging a Deployment Race Condition: How a Previous Agent's Fix Introduced JavaScript Syntax Errors

What Happened

During a development session, Claude 4.5 was tasked with fixing a booking calendar race condition on sailjada.com. The issue was legitimate: the jadaOpenBook() function was opening a modal before availability data had finished loading, creating a poor user experience. However, in addressing this race condition across 22 HTML files in the sailjada site, the agent introduced a critical syntax error that went undetected during the staging deployment.

The root cause: Python format-string syntax (`{{ }}`) was left embedded in JavaScript code, making the staged files invalid and non-functional.

The Original Problem and Intended Fix

The sailjada.com site uses a booking system where users click to open a modal calendar. The race condition manifested as:

  • User clicks "Book Now" → jadaOpenBook() fires immediately
  • Modal opens with no availability data loaded yet
  • Availability data arrives 200-500ms later
  • Calendar re-renders, causing UI flicker and potential interaction issues

The intended fix added a loading state check before opening the modal, waiting for isLoading: false before proceeding. This is a sound architectural decision—never expose interactive UI elements before their data dependencies are satisfied.

The Critical Mistake: Python Templates in JavaScript Context

The sailjada.com infrastructure uses a Python-templated site generation approach. File paths like `/Users/cb/Documents/repos/sites/sailjada.com/index.html` contain production deployment templates with placeholders like {STRIPE_LINK} and {BOOKING_STATE}.

During the 4.5 agent's edits to fix the race condition, it added JavaScript code with this pattern:

const bookingState = {{ isLoading: false }};

The agent failed to distinguish between:

  • Legitimate CSS double-braces: font-weight: {{ weight }}; (valid CSS, meant for template substitution)
  • Invalid JavaScript double-braces: const x = {{ isLoading: false }}; (syntax error; should be = { isLoading: false })

When the files were staged to s3://queenofsandiego.com/_staging/sailjada/, these syntax errors made the JavaScript non-functional. The booking system was completely broken in staging.

Discovery and Scope Assessment

Investigation revealed:

  • Files affected: 22 out of 23 sailjada HTML files contained the broken jadaBookingState code
  • Local state: All local index.html files in `/repos/sites/sailjada.com/` contained the corrupted changes
  • Production state: The live S3 bucket s3://sailjada.com/ was still serving the previous (working) version
  • Staging state: 23 files had been deployed to s3://queenofsandiego.com/_staging/sailjada/ with the syntax errors

The staging bucket also contained unrelated deployments (queenofsandiego.com booking pages, brandicarlile.html subdomain content) that had to be preserved.

Remediation Strategy

Rather than manually fix each of 22 files line-by-line, the optimal approach was:

  1. Restore production versions: Download all working versions from s3://sailjada.com/
  2. Bulk replace locally: Overwrite the corrupted local files with production versions
  3. Selective cleanup: Delete only the sailjada staging files from s3://queenofsandiego.com/_staging/sailjada/, preserving other staging content

This approach was faster and more reliable than attempting to surgically fix broken JavaScript syntax across 22 files. The legitimate race condition fix still needs to be properly implemented, but now with correct JavaScript syntax in a controlled development environment.

Technical Details: The Correct Implementation

The proper fix should look like:

function jadaOpenBook(bookingState) {
  if (bookingState.isLoading) {
    // Show loading indicator, don't open modal yet
    return;
  }
  // Only open modal when data is ready
  openModal();
}

Not:

const bookingState = {{ isLoading: false }}; // WRONG: Python syntax in JS context

The distinction matters because these sailjada files exist in a hybrid environment: Python processes them server-side for template variables, but browsers execute the JavaScript. The agent needed to recognize that new JavaScript logic should use standard JS object literal syntax, not template syntax.

Infrastructure Implications

  • S3 Buckets: s3://sailjada.com/ (production), s3://queenofsandiego.com/ (staging)
  • Local development: `/Users/cb/Documents/repos/sites/sailjada.com/`
  • CloudFront distribution: Serves cached versions from production S3; requires invalidation on updates
  • Deployment flow: Local development → S3 staging bucket → S3 production bucket (with cache invalidation)

Key Decisions and Lessons

Why bulk restoration instead of manual fixes? With 22 corrupted files and a known working reference in production, restoration was lower-risk than attempting surgical fixes. The race condition fix should be re-implemented in a new development branch with proper code review.

Why preserve production while fixing staging? The production booking system was never impacted; all users continued to have a working experience. Staging is specifically for testing before production deployment. This separation meant we could safely restore staging without affecting live traffic.

Why not cherry-pick fixes? Python template processing makes partial fixes dangerous. If you modify only some files but not others, template variable substitution can fail inconsistently. Complete restoration followed by controlled re-implementation is safer.

What's Next

The race condition fix is still valid and needed. The proper next step is:

  • Create a new development branch from the restored production versions
  • Re-implement the race condition fix with correct JavaScript syntax
  • Add syntax validation (ESLint or similar) to catch template/JS context confusion
  • Deploy to staging for testing before production push
  • Monitor CloudFront cache invalidation and TTLs during rollout

Additionally, consider whether the Python template processing should be replaced with a more modern build system (webpack, vite, etc.) that has clearer separation between template and source code contexts.

```