Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Troubleshooting Multi-Site Deployment Pipeline: GA4 Integration, Daemon Health Checks, and CloudFront Cache Invalidation

This session involved diagnosing and resolving issues across three production websites while implementing Google Analytics 4 integration and verifying the health of the jada-agent orchestrator daemon. The work touched infrastructure spanning AWS Lightsail, S3, CloudFront, Route53, and Google Cloud APIs.

What Was Done

  • Authenticated against Google Analytics 4 API using OAuth2 credentials stored in the tools pipeline
  • Migrated the 86dfrom.com site directory to 86from.com with proper S3 and CloudFront cache invalidation
  • Created and deployed a new SEO landing page for the 86from.com property
  • Fixed JavaScript templating syntax errors in booking widget embedded on sailjada.com
  • SSH'd into the jada-agent Lightsail instance (34.239.233.28) to verify daemon health, service status, logs, and task queue processing
  • Identified and documented a critical Google OAuth token expiration affecting the port_sheet_sync.py background task

Technical Details: GA4 API Integration

The session began with establishing authenticated access to Google Analytics 4 for the dangerouscentaur@gmail.com account. The approach used OAuth2 certificate-based authentication rather than user-facing login flows.

Authentication Architecture:

  • Tool location: /Users/cb/Documents/repos/tools/auth_ga.py
  • Authentication method: OAuth2 using stored client credentials (client_id and client_secret)
  • Libraries: google-auth-oauthlib, google-analytics-data
  • Token storage: Credentials cached locally to avoid repeated auth round-trips

The stored credentials include both a client_id and client_secret, eliminating the need to re-authenticate for each GA4 API call. This is critical for background tasks and automation—once authenticated, the token can be reused until it expires (typically 24 hours for OAuth2 refresh tokens).

GA4 Account Structure Verified:

  • Parent account: dangerouscentaur@gmail.com
  • Properties queried: 86dfrom.com (later renamed to 86from.com)
  • Data retrieval: 7-day rolling reports with session counts, user metrics, and engagement data
  • API calls used: RunReport method to fetch custom dimensions and date-range breakdowns

The GA4 integration validates that analytics events are flowing correctly from deployed sites. This is essential before pushing changes to production, as it confirms that instrumentation is working and baseline metrics are established.

Site Migration and S3/CloudFront Deployment

Directory Rename:

The 86dfrom.com directory in the sites repository was renamed to 86from.com to match the intended domain structure. This required updating references across the deployment pipeline.

  • Source directory: /Users/cb/Documents/repos/sites/86dfrom.com
  • Target directory: /Users/cb/Documents/repos/sites/86from.com
  • Content: Static HTML, CSS, and a new SEO-focused landing page at /what-does-86d-mean

S3 and CloudFront Deployment:

After migration, the 86from.com content was deployed to S3 and CloudFront cache was invalidated to ensure users see the latest version immediately:

# Conceptual deployment flow (actual commands redacted)
# 1. Sync updated files to S3 bucket
# 2. Create CloudFront invalidation for /* path pattern
# 3. Verify origin-pull and cache headers are correct

Why Immediate Invalidation Matters:

CloudFront distributions default to a 24-hour TTL for HTML content. Without explicit invalidation after deployment, users would see stale content for up to 24 hours. By invalidating the /* path pattern immediately post-deploy, we force all edge locations to fetch fresh content from the S3 origin on the next user request. This is particularly important for SEO landing pages where content freshness and search engine crawlers (which may cache aggressively) are critical.

Booking Widget JavaScript Debugging

Multiple edits to sailjada.com's index.html revealed a templating syntax error in the embedded booking widget JavaScript. The widget was using double-brace syntax {{ variable }}, which conflicts with JavaScript template literals and causes parsing failures.

Issue Identified:

  • File: /Users/cb/Documents/repos/sites/sailjada.com/index.html
  • Problem: Double braces appeared both inside and outside the booking widget section
  • Root cause: Template variable syntax was not properly escaped or scoped
  • Impact: Booking widget would fail to initialize on page load, preventing user interactions

Resolution:

Replaced double-brace syntax with single braces specifically within the booking widget <script> tag block. This allows the widget's internal variable references to parse correctly while maintaining any external templating (if present) in the rest of the page.

// Before (broken)
<script>
  const bookingData = {{ booking_object }};
  renderBooking(bookingData);
</script>

// After (fixed)
<script>
  const bookingData = { booking_object };
  renderBooking(bookingData);
</script>

After fixes were applied, the corrected index.html was deployed to the staging CloudFront distribution and cache was invalidated. A version tag embedding the model ID was added to the booking widget comment block for tracking and debugging in production.

Jada-Agent Daemon Health Verification

Connection Method:

The jada-key SSH private key was not stored locally. Instead, temporary SSH credentials were obtained via the AWS Lightsail API, allowing secure access to the daemon instance without storing long-lived keys on the development machine.

Instance Details:

  • IP: 34.239.233.28 (Lightsail instance in us-east-1)
  • Service: jada-agent.service (systemd unit)
  • Uptime: 11 days with 3 days of continuous daemon operation since May 10
  • Resource utilization: ~0.65% CPU, 144MB/914MB memory—essentially idle between task processing

Service Health Summary:

The jada-agent.service is running healthily with proper task queue processing. On 2026-05-13, three agent sessions were executed within the daily quota (3 of 5 sessions used):

  • Session 1 (00:00 UTC): Hit maximum turn limit (30 turns) — expected behavior when task complexity requires extended reasoning
  • Session 2 (00:02 UTC): Completed successfully, processed e-signature and crew page generation tasks, created downstream needs-you task
  • Session 3 (00:05 UTC): Hit maximum turn