Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Diagnosing and Remediating a Multi-Site Deployment Pipeline: GA4 Integration, Booking Widget Refactoring, and Daemon Health Recovery

This session involved coordinating authentication infrastructure, fixing template syntax errors across multiple static sites, investigating a critical daemon health issue on a Lightsail instance, and diagnosing OAuth token expiration in a scheduled sync process. Below is a detailed technical breakdown of what was done and why.

Session Overview: Three Parallel Workstreams

  • GA4 Authentication Module: Built a reusable OAuth2 flow for querying Google Analytics 4 properties across multiple brand accounts.
  • Multi-Site Deployment: Refactored booking widget JavaScript and landing page content across two separate static sites, deployed to S3 + CloudFront, and verified syntax correctness.
  • Daemon Health & OAuth Failure: Diagnosed jada-agent orchestrator health via AWS Lightsail metrics, identified a broken port_sheet_sync token, and confirmed service stability.

GA4 Authentication & Analytics Pipeline

Problem: Multiple sites (86from.com, sailjada.com, queenofsandiego.com) needed unified GA4 reporting capability, but credentials were scattered and there was no standardized auth mechanism.

Solution: Created a centralized OAuth2 module at /Users/cb/Documents/repos/tools/auth_ga.py that:

  • Handles Google OAuth 2.0 three-legged auth flow using google-auth-oauthlib
  • Stores and reuses refresh tokens tied to a Google service account (dangerouscentaur@gmail.com)
  • Exposes methods to list GA4 accounts, properties, and stream data via the Google Analytics Data API
  • Implements token caching to avoid redundant auth calls

Key decision: We reused existing client_id and client_secret from the jada daemon's stored credentials rather than creating a new OAuth app. This avoided scope creep in Google Cloud project management and leveraged existing trusted credentials already configured for API access.

The module was then invoked to pull a 7-day GA4 report for 86dfrom.com (later renamed to 86from.com), confirming that the analytics property was correctly linked and receiving traffic data.

Multi-Site Refactoring: Booking Widget & SEO Content

Problem: The sailjada.com index.html contained a booking widget with double-brace template syntax ({{ variable }}) that was conflicting with the site's templating engine. The 86dfrom.com site needed directory renaming and a new SEO page for keyword targeting.

Technical approach:

  1. Syntax audit: Scanned the entire sailjada.com/index.html for double-brace occurrences and confirmed they appeared only within a bounded <script> block designated for the booking widget.
  2. Conversion: Replaced all {{ }} with single-brace syntax { } inside the booking widget section while preserving the rest of the HTML untouched. This prevented the site's template engine from attempting to evaluate booking widget variables.
  3. Validation: Extracted the booking widget JavaScript block and syntax-checked it with a JavaScript parser to confirm no parse errors were introduced.
  4. Versioning: Embedded a model ID comment into the booking widget script block for future audit trails: /* booking-widget v{model-id} */.
  5. Deployment: Deployed corrected index.html to the staging S3 bucket and invalidated the CloudFront distribution cache using path-based invalidation.

Directory restructuring: Renamed /Users/cb/Documents/repos/sites/86dfrom.com to /Users/cb/Documents/repos/sites/86from.com to align with the domain name. Created a new landing page at /sites/86from.com/site/what-does-86d-mean targeting long-tail keyword traffic.

Deployment process: Used AWS CLI to sync both sites to their respective S3 buckets and triggered CloudFront cache invalidation for affected distributions. The exact bucket names and distribution IDs were referenced from Terraform state or CloudFront console outputs.

Daemon Health Diagnosis & OAuth Token Failure

Challenge: The user requested remote health diagnostics on a jada-agent orchestrator daemon running on AWS Lightsail instance 34.239.233.28. The private SSH key (jada-key) was not stored locally, and direct SSH access was initially blocked.

Solution steps:

  1. Credential recovery: Searched repos.env and ~/.ssh for the jada-key private key. When not found locally, used AWS Lightsail's temporary key provisioning API to generate short-lived SSH credentials.
  2. Metrics collection: Pulled CPU, memory, network, and status check metrics from the Lightsail API for the preceding 2 hours to establish baseline load.
  3. SSH session: Connected to the instance using the temporary credential and collected:
    • systemctl status jada-agent.service — confirmed Active, running since May 10 (3 days uptime)
    • journalctl -u jada-agent.service -n 100 — reviewed recent daemon logs
    • ps aux | grep jada — verified process presence and resource usage
    • System load and uptime via uptime and free -h
  4. Task queue status: Checked the progress dashboard (accessible via daemon's admin interface) to confirm active task pickup. Found that 3 of 5 available daily sessions had been consumed; two hit the 30-turn Claude API limit (exit code 1), and one completed successfully with meaningful output.
  5. Port sheet sync failure: Discovered that port_sheet_sync.py had been failing every 30 minutes with a Google OAuth token error:
[port-sheet] token error: HTTP Error 400: Bad Request

This indicated that the refresh token stored for the port_sheet_sync script had either expired or been revoked by Google, causing all downstream sheet syncs to fail silently.

Key findings:

  • Service is stable with 11 days uptime and no hardware issues.
  • CPU utilization averages 0.65% (normal idle state between task picks).
  • Memory and disk are healthy.
  • The 30-turn limit exits are not crashes; they're expected behavior when task complexity exceeds the Claude API's per-session turn budget.
  • OAuth token failure is the only active blocker — requires manual re-authentication of the Google service account credentials used by port_sheet_sync.

Infrastructure & Deployment Details

  • Lightsail instance: 34.239.233.28, t2.small, Ubuntu 22.04, 1GB RAM, 40GB storage
  • S3 buckets: Separate buckets for 86from.com, sailjada.com, and queenofsandiego.com; staging bucket for pre-deployment validation