Debugging a Multi-Site Deployment Pipeline: GA4 Integration, Domain Migration, and Daemon Health Monitoring

This session involved coordinating infrastructure changes across three distinct properties while troubleshooting authentication failures in a background orchestrator daemon. The work spanned Google Analytics 4 API integration, domain migration and SEO optimization, booking widget fixes, and remote system diagnostics via AWS Lightsail.

What Was Done

• Migrated 86dfrom.com to 86from.com with S3 deployment and CloudFront cache invalidation
• Created and deployed SEO-optimized content page for restaurant terminology
• Fixed template syntax errors in booking widget JavaScript (double-brace escaping)
• Established GA4 Data API access via OAuth and pulled historical analytics reports
• Diagnosed remote jada-agent orchestrator daemon health via Lightsail SSH and API metrics
• Identified and documented a broken port sheet sync token requiring re-authentication

Technical Details: Domain Migration and Site Deployment

The 86dfrom.com directory was renamed to 86from.com to correct the domain naming convention. This required careful handling because the directory path is referenced in deployment automation.

File structure before:

/Users/cb/Documents/repos/sites/86dfrom.com/site/
  ├── index.html
  └── [content files]

File structure after:

/Users/cb/Documents/repos/sites/86from.com/
  ├── site/
  │   └── index.html
  └── site/
      └── what-does-86d-mean/
          └── [SEO page]

The migration was followed by deployment to an S3 bucket (specific bucket name omitted for security). The deployment process includes CloudFront cache invalidation to ensure edge locations serve fresh content immediately. This is critical for SEO — search engines crawl fresh content more aggressively when cache headers are properly managed.

A new SEO-optimized page was created at /Users/cb/Documents/repos/sites/86from.com/site/what-does-86d-mean to capture long-tail search traffic around restaurant industry terminology. This page was deployed to production S3 and the CloudFront distribution was invalidated using /* pattern to clear all cached versions.

Booking Widget Fix: Template Syntax and JavaScript Parsing

The sailjada.com/index.html file underwent 16 edit iterations during this session. The root cause: double-brace template syntax {{ }} was conflicting with JavaScript execution within a booking widget embedded as a script tag.

Problem: Template systems like Handlebars use {{ }} for variable interpolation. When these appear in JavaScript code, they can be misinterpreted by template engines or cause parsing ambiguity.

Solution: Replaced all {{ and }} with single braces { and } only within the booking widget JavaScript block, while preserving any legitimate template syntax outside that section. The fix was validated by extracting the script tag and running it through a JavaScript syntax checker to confirm no parsing errors were introduced.

A versioning comment was embedded into the widget with a model ID to track which version of the booking widget is deployed. This allows rapid identification of which widget version is running in production and correlates with git commit history.

Deployment flow:

• Fixed HTML deployed to staging S3 bucket first
• CloudFront staging distribution invalidated to verify changes
• After validation, production deployment occurred with full cache invalidation

Google Analytics 4 Integration and Data Access

Created /Users/cb/Documents/repos/tools/auth_ga.py to manage OAuth2 authentication with Google Analytics 4 Data API. The script establishes reusable credentials for querying GA4 properties without manual dashboard access.

Authentication flow:

• Script uses google-auth-oauthlib library to obtain OAuth2 token
• Token is securely stored with restricted file permissions (600) to prevent accidental exposure
• Subsequent requests reuse stored token, eliminating the need for repeated browser-based auth flows
• Account: dangerouscentaur@gmail.com (GA4 account owner)

Data retrieval: Script successfully enumerated all GA4 properties under the account and pulled a full 7-day historical report for 86dfrom.com (now 86from.com). This enables programmatic access to analytics without UI dependency, supporting automated reporting and anomaly detection workflows.

Why this matters: A data-driven approach to monitoring site performance allows the team to correlate infrastructure changes (like the domain migration) with user behavior metrics. Session counts, bounce rates, and traffic sources become part of the observability stack.

Infrastructure: Remote Daemon Health Diagnostics

The jada-agent orchestrator daemon runs on an AWS Lightsail instance at 34.239.233.28. Standard SSH key lookup failed, necessitating an alternative access method.

Access strategy:

• First attempt: Local SSH key lookup in ~/.ssh/ and repos configuration — failed
• Second attempt: AWS Lightsail GetInstanceAccessDetails API to retrieve temporary SSH credentials — successful
• Temporary key written to disk, SSH connection established, diagnostics collected, temporary key deleted

Metrics collected via SSH:

systemctl status jada-agent.service
journalctl -u jada-agent.service -n 100
ps aux | grep jada
free -h
df -h
uptime

Metrics collected via Lightsail API:

• CPU utilization (last 2 hours): ~0.65% average, no spikes
• Network traffic: minimal
• Status checks: 0 failures
• Memory: 144MB / 914MB (15.7% used)
• Disk: 6.2GB / 39GB (17% used)

Service status: jada-agent.service is active and running with 11 days uptime. The daemon implements a 60-second polling loop and correctly enters idle state when no tasks are queued.

Critical Issue: Broken OAuth Token in Port Sheet Sync

The daemon logs revealed a persistent failure in port_sheet_sync.py`:

[port-sheet] token error: HTTP Error 400: Bad Request