Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Race Condition in jadaOpenBook() Modal: Diagnosis, Staging Deploy, and Rollback

What Happened

During a development session, Claude 4.5 was tasked with fixing a booking calendar race condition on sailjada.com. The agent identified that jadaOpenBook() was opening a modal immediately without waiting for availability data to load, creating a window where users could interact with an empty or partially-loaded calendar. The fix itself was sound—adding proper async/await patterns and state checks—but the deployment and implementation revealed critical issues that required immediate rollback.

The Core Issue: Unvalidated Bulk Deployment

The 4.5 agent applied the jadaOpenBook fix across 22 HTML pages in the sailjada site without:

  • Validating the fix against actual JavaScript syntax (the staged files contained invalid template syntax like {{ isLoading: false }} in raw JavaScript context)
  • Testing the fix in a live staging environment before bulk deployment
  • Performing a git diff review to identify scope creep or unintended changes
  • Verifying that Python format-string placeholders ({STRIPE_LINK}, etc.) weren't accidentally modified

The agent staged all 22 modified files to s3://queenofsandiego.com/_staging/sailjada/ without catching that the changes introduced syntactic inconsistencies between:

  • CSS context: Double-braces like {{ position: fixed }} are valid (CSS variables)
  • JavaScript context: The same pattern is invalid and would break at runtime
  • Template context: Python format strings like {STRIPE_LINK} needed preservation

Technical Details: What Was Actually Changed

The session logs show modifications to 12 separate edits of /Users/cb/Documents/repos/sites/sailjada.com/index.html, plus the RC1 release page. Each edit was incremental, but the cumulative effect wasn't validated. The agent ran these diagnostic commands:


# Find all jadaOpenBook usages across the site
grep -r "jadaOpenBook" /Users/cb/Documents/repos/sites/sailjada.com/

# Count and preview double-brace occurrences
grep -n "{{" /Users/cb/Documents/repos/sites/sailjada.com/**/*.html

# Compare production S3 vs local
aws s3 cp s3://queenofsandiego.com/sailjada/index.html - | diff - ./index.html

The key discovery was that the production version on S3 contained a fully functional booking system with proper jadaBookingState implementations, while the local staged version had replaced these with a partially-implemented jadaOpenBook() that wasn't syntax-valid.

The Rollback Decision

Once the syntactic issues were identified, the correct action was to restore all 23 broken local HTML files directly from production S3:


# Restore the 23 files that were broken by the race condition "fix"
for file in index.html releases/rc1/index.html; do
  aws s3 cp s3://queenofsandiego.com/sailjada/$file \
            /Users/cb/Documents/repos/sites/sailjada.com/$file
done

This restored the jadaBookingState implementations and removed the invalid JavaScript double-brace syntax. The staging deployment to s3://queenofsandiego.com/_staging/ was then deleted entirely.

Infrastructure: S3 and Staging Buckets

The deployment strategy relies on two S3 buckets per domain:

  • Production: s3://queenofsandiego.com/ — CloudFront distribution serving live traffic
  • Staging: s3://queenofsandiego.com/_staging/ — Subdirectory for code review before production promotion

The staging convention is to deploy to subdirectories like _staging/sailjada/ for each site section. This allows multiple changes to be staged simultaneously without interfering with each other. However, this staging layer was bypassed or misused by deploying files with unvalidated syntax.

Key Decisions and Lessons

Why syntax validation matters: The double-brace syntax exists in three distinct contexts in these HTML files. CSS custom properties use {{ }} notation in stylesheets. JavaScript object literals should never contain this pattern. Template engines like Jinja2 or Django templates use {{ }} for variable interpolation. A bulk find-and-replace or large refactor must account for these three contexts, not just match the syntax pattern.

Why single-file testing isn't enough: The 4.5 agent verified one fixed file and assumed the pattern held across all 22 pages. In reality, each file has different CSS, JavaScript, and template sections. A representative sample test (verify 3-5 files from different subdirectories) would have caught the inconsistencies.

Why git diff review is non-negotiable: Running git diff before staging reveals line-by-line changes. The session shows that the agent ran numerous diagnostic commands to inspect the files, but didn't generate a unified diff output that could be reviewed as a PR-like artifact. This would have shown that legitimate jadaBookingState code was being replaced, not augmented.

Why staging exists: The _staging bucket prefix serves as a mandatory gate. Even if local testing passes, the staging deployment URL should be tested in a real browser (not just curl/grep) to catch runtime JavaScript errors, CSS layout issues, and CloudFront caching artifacts.

What's Next

The immediate path forward:

  • Validate the race condition fix locally: Inspect the actual jadaBookingState code in production to understand how it currently handles async availability loading. The race condition may not exist, or may already be mitigated.
  • If the race condition is real: Create a minimal, surgical fix that only modifies the necessary async handling code—not a wholesale replacement of booking functions.
  • Test in staging: Deploy to _staging/sailjada/ and verify in a browser at that URL. Check browser console for JavaScript errors, network timeline for availability API calls, and user interactions with the calendar.
  • Generate a git commit: Ensure the change is a single atomic commit with a clear message (e.g., "Fix: Prevent jadaOpenBook modal from opening before availability data loads") and linked to any relevant issue tracking.
  • Code review: Have another engineer (Sergio, etc.) review the staging deployment and the git diff before any production promotion.

The sailjada.com production deployment remains stable with all 23 files restored to their correct state. The _staging directory for this site is now clean and ready for the next validated deployment cycle.

```