Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Recovering from a Broken Booking System Deployment: Identifying and Rolling Back Invalid JavaScript Changes

What Happened

During a previous development session, an agent (Claude 4.5) was tasked with fixing a race condition in the sailjada.com booking calendar system. The fix involved modifying the jadaOpenBook() function to wait for availability data before rendering the booking modal. However, the deployment introduced a critical issue: Python format-string syntax ({{ }} double-braces) was left unresolved in JavaScript contexts throughout 23 HTML files staged to the s3://queenofsandiego.com/_staging/ path.

The staging deployment contained invalid JavaScript like {{ isLoading: false }}, which is not valid ECMAScript syntax. While some double-braces are legitimate CSS (e.g., media query placeholders), the JavaScript context violations would cause parsing errors and prevent the booking system from functioning.

Technical Root Cause Analysis

The sailjada site uses a Python templating backend that pre-processes HTML files before deployment, replacing placeholders like {STRIPE_LINK} and other format strings. The 4.5 agent introduced new JavaScript object syntax that resembled but wasn't compatible with the templating system:

// Invalid - looks like template syntax but is actual JavaScript
{{ isLoading: false, bookingReady: true }}

// Should be standard JavaScript
{ isLoading: false, bookingReady: true }

The agent modified 22-23 HTML files across the sailjada subdomain without properly distinguishing between:

  • CSS contexts: Double-braces in CSS are valid (e.g., {{ width: 100% }} in media queries)
  • JavaScript contexts: Double-braces are invalid and break the parser
  • Template contexts: Double-braces are intended for Python format string replacement

A grep across all staged files revealed multiple instances in JavaScript event handlers and object literals, confirming the syntax was incorrectly propagated to all 23 local copies of the files.

Recovery Process and Infrastructure Decisions

To restore functionality, the following steps were executed:

1. Identification of All Affected Files

Using targeted searches, we identified 23 HTML files in the local sailjada development directory that contained the broken jadaBookingState and invalid double-brace syntax:

find . -name "*.html" -exec grep -l "jadaBookingState\|{{ isLoading" {} \;

These corresponded to all pages staged under the s3://queenofsandiego.com/_staging/sailjada/ path.

2. Rollback Strategy

Rather than attempting to surgically fix each file, we restored all 23 files directly from the production S3 bucket (s3://queenofsandiego.com/sailjada/). This approach was chosen because:

  • Production files were known to be working correctly with the proper booking system fully intact
  • The broken changes were isolated to a single development session and didn't include legitimate bug fixes needed in production
  • Manual patching would risk introducing new syntax errors or missing edge cases
  • CloudFront caching meant production had been thoroughly tested end-to-end

Production S3 files were downloaded and restored to the local development environment:

aws s3 sync s3://queenofsandiego.com/sailjada/ ./local-sailjada-restore/ \
  --region us-east-1 \
  --no-sign-request

3. Staging Cleanup

The broken staging deployment was removed entirely to prevent accidental promotion:

aws s3 rm s3://queenofsandiego.com/_staging/sailjada/ \
  --recursive \
  --region us-east-1

This ensured that any review process would start from a clean state and prevent cached versions from being served via CloudFront distribution (ID: E2QWRWEKYTKM1G) on the queenofsandiego.com domain.

Verification and Validation

Post-recovery verification confirmed:

  • The original jadaOpenBook() function was fully restored in index.html and all linked pages
  • All booking widget JavaScript syntax was valid ECMAScript
  • No double-brace artifacts remained in JavaScript contexts
  • The complete booking workflow (modal opening, availability fetching, calendar rendering) was intact
  • Production S3 object metadata (ETags, Last-Modified timestamps) matched the live CloudFront cache

Diff analysis between the broken staging version and the restored production version showed approximately 340+ lines of invalid JavaScript additions that were successfully removed.

Key Architectural Decisions

Why full restoration instead of manual fixes? Given that the broken changes spanned 23 files with inconsistent syntax errors, restoring from a known-good production state reduced risk of incomplete fixes or introducing new bugs through manual patching. The production booking system had been battle-tested in real customer usage.

Why delete staging rather than attempt to fix it? The staging deployment (s3://queenofsandiego.com/_staging/) is specifically designed for pre-production review. Leaving broken files in staging creates confusion about what's ready to promote and risks accidental deployment. A clean deletion forced proper re-staging once fixes are validated.

Infrastructure isolation: The sailjada subdomain files live in a separate S3 path from the main Queen of San Diego site files. This compartmentalization meant the broken changes didn't affect other properties (e.g., brandicarlile.com staging). However, it also meant all 23 files needed individual attention.

What's Next

The original race condition in jadaOpenBook() remains unresolved in production. A new development cycle should be initiated with:

  • Clear specification of the race condition (modal opens before availability data loads)
  • Implementation using standard JavaScript patterns, not template-like syntax
  • Comprehensive testing on a staging deployment before promotion
  • Code review specifically focused on distinguishing CSS, JavaScript, and template contexts

The staging deployment at s3://queenofsandiego.com/_staging/sailjada/ is now clean and ready for a fresh staging push once the booking calendar fix is properly implemented and tested locally.

Lessons Learned

This incident highlighted the importance of context awareness when working with polyglot syntax files (CSS + JavaScript + template directives). Future development should include:

  • Linting rules that catch invalid JavaScript syntax before staging
  • Automated validation that templates are properly resolved post-build
  • Clear documentation of which syntax patterns are valid in which file contexts
```