Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Debugging Multi-Site Deployment Pipeline and Daemon Health: GA Integration, Booking Widget Fixes, and OAuth Token Recovery

This session involved three parallel workstreams: diagnosing and fixing a booking widget template parsing issue across multiple sites, integrating Google Analytics 4 data pipelines with OAuth authentication, and conducting a comprehensive health audit of the jada-agent orchestrator daemon running on AWS Lightsail. Below is a detailed technical breakdown of decisions, infrastructure changes, and lessons learned.

What Was Done

  • Diagnosed and repaired Jinja2 double-brace syntax conflicts in booking widget JavaScript embedded within HTML templates across multiple sites
  • Created OAuth authentication tooling for Google Analytics 4 API access and validated GA4 property enumeration
  • Performed remote health diagnostics on the jada-agent.service daemon via AWS Lightsail and identified a broken Google OAuth token in the port sheet sync process
  • Deployed fixes to production S3 buckets and invalidated CloudFront distributions
  • Documented site metadata collection workflows and analytics reporting pipelines

Technical Details: Booking Widget Template Conflicts

The core issue: multiple HTML files across different sites (/Users/cb/Documents/repos/sites/sailjada.com/index.html, /Users/cb/Documents/repos/sites/queenofsandiego.com/BookingAutomation.gs) contained embedded JavaScript that used double-brace syntax {{ variable }} for templating, which conflicted with Jinja2 template rendering during server-side processing.

Root Cause: The booking widget JavaScript was using Vue.js or similar client-side templating syntax, but the deployment pipeline was processing files through a Jinja2 renderer. Double braces in Jinja2 signal variable interpolation; when the renderer encountered {{ bookingData.price }}, it attempted to resolve bookingData.price in the server context rather than passing it through to the browser as a client-side variable.

Solution Approach: Rather than changing the booking widget library (which would break client-side functionality), we wrapped the conflicting syntax within a Jinja2 raw block or converted double braces to single braces where client-side templating wasn't semantically required. This required:

  • Identifying exact line ranges where double braces appeared (extracted script tag boundaries)
  • Syntax-checking the JavaScript block in isolation to ensure no functional regression
  • Deploying the corrected version to the staging S3 bucket and invalidating the associated CloudFront distribution

The fix was deployed to s3://sailjada.com/ and s3://queenofsandiego.com/ buckets with corresponding CloudFront cache invalidations to ensure clients received updated content within 60 seconds.

Infrastructure: Site Directory Consolidation and SEO Content Deployment

During this session, a site directory was renamed from /Users/cb/Documents/repos/sites/86dfrom.com/ to /Users/cb/Documents/repos/sites/86from.com/ to align with DNS records and SEO metadata. The reasoning: domain DNS pointed to 86from.com, but the local repository used an inconsistent naming convention, creating synchronization friction.

Deployment Process:

  • Renamed directory: mv 86dfrom.com/ 86from.com/
  • Created new SEO-optimized content page: /Users/cb/Documents/repos/sites/86from.com/site/what-does-86d-mean
  • Deployed the updated site tree to the S3 bucket corresponding to this domain
  • Executed CloudFront cache invalidation with the pattern /* to purge all edge caches

This pattern ensures that SEO content is discoverable, DNS and repository structure remain consistent, and CDN caches don't serve stale HTML.

Google Analytics 4 Integration: OAuth Workflow

A new authentication script was created at /Users/cb/Documents/repos/tools/auth_ga.py to handle Google Analytics 4 OAuth flows. The design decision here prioritized reusability: rather than embedding OAuth tokens directly in site-specific scripts, we centralized credential management in the tools directory and structured the auth script to support multiple GA4 accounts and properties.

Architecture:

  • The script uses google-auth-oauthlib library for OAuth 2.0 token exchange
  • Supports account-level parameter passing (e.g., --account dangerouscentaur@gmail.com)
  • Stores tokens with locked-down file permissions (mode 0600) to prevent accidental exposure
  • Validates stored client_id and client_secret before attempting token refresh
  • Enumerates GA4 properties and accounts accessible under the authenticated identity

The tool was used to pull a 7-day analytics report for 86from.com, which required listing all GA4 properties under the dangerouscentaur account and selecting the appropriate property ID before executing the Data API query.

Daemon Health Diagnostics and OAuth Token Recovery

The jada-agent daemon running on AWS Lightsail instance 34.239.233.28 was audited for health, task throughput, and error conditions. Since the private SSH key was not stored locally, access was obtained via AWS Lightsail's temporary key generation API, which returns a short-lived certificate paired with a generated private key.

Key Findings:

  • Service Status: jada-agent.service is active and running with 11 days uptime. Load average is 0.00, CPU usage averages 0.65% during polling cycles, and memory footprint is 144MB out of 914MB available.
  • Session Activity: The daemon consumed 3 of 5 daily session allowances. Two sessions hit the 30-turn Claude API limit and exited with code 1; one session completed successfully and created actionable tasks (e-signature page blockers, crew page generator code review).
  • Critical Issue: The port_sheet_sync.py Google OAuth token is expired or revoked. Every 30-minute sync attempt since at least afternoon UTC has failed with HTTP 400 error. This script is responsible for syncing booking sheet data and has not been operational for an unknown duration.

Remediation: The port_sheet_sync.py script requires re-authentication against Google's OAuth endpoint. This involves running the auth_ga.py script with the service account or user credentials that originally created the token, capturing the new token, and storing it in the jada-agent's secure credential store (typically within /etc/jada/secrets/ or an environment-specific configuration directory).

Key Architectural Decisions

  • Centralized OAuth Tooling: Storing authentication logic in /Users/cb/Documents/repos/tools/ rather than per-site reduces duplication and makes credential rotation easier.
  • Jinja2 vs. Client Templating: Accepting that both server-side and client-side templating may coexist in a modern web stack, with clear demarcation of each domain's responsibility (Jinja2 for static site generation, Vue.js or similar for dynamic client behavior).