Diagnosing and Reverting a Race Condition Fix Gone Wrong: Sailjada Booking Calendar Deployment
What Happened
During a recent development session, an agent (4.5) was tasked with fixing a race condition in the Sailjada booking calendar system. The issue: jadaOpenBook() was opening the booking modal before availability data finished loading, creating a poor UX where users could interact with an empty calendar.
The fix appeared successful—22 HTML files were updated and staged to s3://queenofsandiego.com/_staging/sailjada/ for review. However, a careful audit of the staged files revealed critical problems that prevent production deployment.
The Core Problems Discovered
1. Invalid JavaScript Syntax in Production Template
The staged files contain Python format-string placeholders like {{ isLoading: false }} and {STRIPE_LINK} embedded in JavaScript and HTML. These are template markers meant to be replaced during server-side rendering, but they're malformed:
// INVALID - in staged sailjada/index.html
const bookingState = {
{{ isLoading: false }} // This is not valid JavaScript
};
This syntax will cause immediate JavaScript parse errors in the browser. The double-braces ({{...}}) are legitimate only in CSS (for custom property fallbacks or in CSS-in-JS contexts), not in raw JavaScript object literals.
2. Incomplete Template Variable Replacement
The {STRIPE_LINK} placeholder appears in multiple files but was never replaced with the actual Stripe payment URL. Checking production S3 reveals the correct implementation—the placeholder should be fully substituted before deployment.
3. Scope Creep Beyond the Race Condition Fix
The git history shows that 4.5's changes extended far beyond the stated goal of fixing jadaOpenBook() timing. Files were modified that should have remained untouched, and the production booking system (which was working correctly) was partially replaced with a broken new implementation called jadaBookingState.
Technical Investigation Results
File Count and Status
- Total HTML files modified: 22 across sailjada.com and queenofsandiego.com properties
- Staged location:
s3://queenofsandiego.com/_staging/sailjada/(22 files) - Production location:
s3://queenofsandiego.com/(verified working versions) - Broken template syntax instances: Found across all 22 staged files via pattern matching on
{{and}}
What Should Have Changed vs. What Actually Changed
The stated fix required:
- Modify the timing logic in
jadaOpenBook()to wait forwindow.bookingDatato be populated - Test with existing production booking implementation
- Deploy incrementally for validation
What was actually changed:
- Complete replacement of booking logic with untested
jadaBookingStateobject - Introduction of template placeholders that were never filled
- Changes to payment flow integration with Stripe
- Modifications to 22 files when the fix should have touched perhaps 2-3
Production Verification
We verified the production S3 files to understand the correct baseline:
aws s3 ls s3://queenofsandiego.com/ --recursive | grep -E "\.(html|js)$" | head -20
Production files show:
- Proper Stripe integration with fully resolved URLs
- Valid JavaScript syntax throughout
- Working
jadaOpenBook()function with race condition present but functional - No template placeholders remaining
Remediation Strategy: Full Revert
Given the scope of problems and the number of modified files, the safest path forward is:
Step 1: Restore Production Versions (COMPLETED)
// Download all 22 files from production S3
aws s3 sync s3://queenofsandiego.com/ ./prod-backup/ --exclude "*" --include "*.html"
// Copy back to local development
cp -r ./prod-backup/* ./sailjada/
All 23 broken local HTML files were restored from production backups. The jadaBookingState code was completely removed.
Step 2: Delete Staging Deployment (COMPLETED)
// Remove the problematic staged files
aws s3 rm s3://queenofsandiego.com/_staging/sailjada/ --recursive
The staging bucket no longer contains any broken code.
Step 3: Proper Fix Implementation (IN PROGRESS)
The race condition in jadaOpenBook() is still a valid issue that needs fixing. The proper approach:
- Create a minimal patch targeting only the timing logic in
jadaOpenBook() - Preserve all existing production infrastructure (Stripe integration, template variables, etc.)
- Test on a single file first before rolling to all 22
- Use Git commits to track every change granularly
Key Decisions Made
Why Full Revert Instead of Selective Cherry-Picking?
With 22 modified files and interrelated booking logic, identifying which specific changes were intentional vs. side-effects would be time-consuming and error-prone. A full revert to the known-good production state provides confidence that all functionality works while we develop a focused fix.
Why Not Deploy Staged Files with Template Fixes?
Even after fixing the template syntax, we wouldn't know if the underlying jadaBookingState logic was correct. The previous approach of modifying in isolation was abandoned for good reason—booking systems have complex interdependencies (payment processing, availability checking, user state management). These need careful integration testing, not broad multi-file changes.
What's Ready for Production
Nothing from the 4.5 session. Production remains stable with the original race condition present but all systems functional.
What Needs Testing
- A minimal
jadaOpenBook()timing fix, written from scratch - Single-file testing with manual calendar interaction
- Verification that availability data loads before modal opens
- End-to-end Stripe payment flow validation
- Cross-browser testing (Chrome, Safari, Firefox)
- Staged deployment to
s3://queenofsandiego.com/_staging/sailjada/with only the corrected file - Approval from product team before production push
Next Steps
A new focused development session should begin with clear acceptance criteria: fix the race condition with a diff touching no more than 5 lines in index.html