Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

# Incident Analysis: Incomplete Booking Widget Migration and Staged Deployment Issues

Debugging a Failed jadaOpenBook Refactor Across 22 Pages of sailjada.com

What Happened

A previous agent (4.5) attempted to fix a booking calendar race condition on sailjada.com by refactoring the jadaOpenBook() function across 22 HTML pages. The agent staged changes to s3://queenofsandiego.com/_staging/sailjada/ for review, but the staged deployment contains multiple critical issues that prevent production readiness:

  • Unresolved Python format-string placeholders ({{ variable }} syntax) left in JavaScript context
  • Incomplete migration from template variables to hard-coded values
  • Race condition fix logic unclear from staged file inspection
  • No clear changelog documenting what the original race condition was or how it was resolved

Root Cause Analysis

The agent's process revealed several implementation gaps:

1. Template Syntax Confusion

The codebase mixes Jinja2/Python template syntax ({{ variable }}) with JavaScript object literals. The agent correctly identified that most double-braces were legitimate CSS (e.g., {{ isLoading: false }} in CSS media queries or styled-component globals), but failed to replace Python placeholders like {STRIPE_LINK} with actual values before deploying.

2. Incomplete Variable Substitution

Production files at s3://queenofsandiego.com/sailjada/index.html contain resolved values (actual Stripe links, booking endpoint URLs), while staged files in s3://queenofsandiego.com/_staging/sailjada/ still contain template syntax. This suggests the deployment pipeline either:

  • Failed to run the template rendering step
  • Uploaded source files instead of built/rendered files
  • Skipped the pre-deployment validation step

3. Git History Gap

Checking git log sailjada.com showed no recent commits corresponding to the staged changes, indicating the agent modified files locally but didn't commit or didn't verify what was actually being staged from disk vs. what was checked into version control.

Infrastructure State

S3 Buckets Involved:

  • s3://sailjada.com/ — Primary sailjada domain bucket (23 HTML files)
  • s3://queenofsandiego.com/sailjada/ — Production deployment of sailjada content
  • s3://queenofsandiego.com/_staging/sailjada/ — Staging area with incomplete changes
  • s3://queenofsandiego.com/ — Main QOS homepage (also has staging versions)

CloudFront & DNS:

Both sailjada.com and queenofsandiego.com are fronted by CloudFront distributions. The staging bucket uses the same CloudFront distribution as production but with a _staging/ prefix route. This means any cached objects in CloudFront will be stale; cache invalidations needed before testing:

aws cloudfront create-invalidation \
  --distribution-id [DIST_ID] \
  --paths "/_staging/sailjada/*"

What's Ready vs. What Needs Work

NOT Ready for Production:

  • All 22 sailjada.com pages in staging — Contain unresolved Python template syntax. Must be rendered/built before deploy.
  • QOS index.html staged version — Diff shows significant content removal (booking widget changes, homepage sections deleted). Unclear if intentional or collateral damage from the race condition fix scope.
  • Brandicarlile subdomain page — Staged version differs from production; unclear what the change purpose was or if it's related to the booking refactor.

Needs Testing:

  • The actual race condition fix logic — what exactly changed in jadaOpenBook()? The staged files don't clearly show the before/after of the modal initialization flow.
  • Booking availability data fetch timing — does it now properly wait for the API response before opening the modal?
  • Cross-browser compatibility of any new Promise/async patterns introduced.

Recommended Actions:

  1. Halt production deployment — Do not push staged files to production without resolving template syntax.
  2. Render/build staged files — Run the template substitution pass (likely a Python script or build step) that replaces {STRIPE_LINK}, {BOOKING_ENDPOINT}, etc., with actual values from environment config.
  3. Audit diff scope — Compare staged QOS index.html against production line-by-line. Confirm whether booking widget changes and content removal are intentional or unintended side effects.
  4. Clarify race condition fix — Document what the original issue was (e.g., "modal opens before GET /api/availability returns, showing stale/empty calendar") and how the new code prevents it (e.g., "modal state is now gated by availability state: if (!availabilityLoaded) return").
  5. Request code review from Carole (CB) — Get explicit sign-off on the booking widget logic before production deploy. Include screenshots or recordings of the modal opening flow.

Key Decisions Going Forward

Build vs. Source Files: The production S3 buckets should always contain built/rendered files, never raw templates. If templates are needed for flexibility, add a pre-deployment build step to the CI/CD pipeline that renders them with environment-specific values before upload.

Staging Strategy: The current _staging/ prefix approach is viable, but requires:

  • Explicit CloudFront cache invalidation after each staging deploy
  • Clear test case documentation for each staged change
  • Approval gates before promotion to production

Version Control Hygiene: All file changes should be committed to git with clear commit messages before staging or production deploy. This allows easy rollback and audit trails.

Next Steps

The staged deployment should be deleted or left as-is until the template rendering issues are resolved. Contact Carole for explicit approval of the booking widget changes and clarity on the original race condition scope. Once approved, re-run the build/render step and re-stage to a clean deployment path.