Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Diagnosing and Stabilizing the JADA Agent Daemon: Health Checks, OAuth Token Failures, and Turn Limit Management

Over a development session spanning multiple sites and infrastructure components, we performed a comprehensive health audit of the JADA agent orchestrator daemon running on AWS Lightsail instance 34.239.233.28. The goal was to verify daemon stability, check for service errors, and confirm task processing. What we discovered was a mostly healthy system with one critical OAuth token failure and a recurring architectural constraint worth documenting.

What Was Done

  • Established SSH access to the Lightsail instance via AWS Systems Manager Session Manager (when direct SSH key wasn't available locally)
  • Collected daemon service status, uptime, resource utilization, and recent logs
  • Analyzed three task sessions executed within a 24-hour window
  • Identified a broken Google OAuth token for the port_sheet_sync.py script failing every 30 minutes
  • Documented the 30-turn Claude API limit as a recurring constraint in agent session design
  • Verified no infrastructure failures, crashes, or system resource issues

Technical Details: Daemon Health and Activity

Service Status and Uptime

The jada-agent.service systemd unit has been active and running since May 10, 2026, giving it 3 days of continuous uptime. The instance itself has been up for 11 days without restart. Load average sits at 0.00, indicating the daemon's polling loop (approximately 60-second intervals when idle) is not causing resource contention. This is the expected behavior for an orchestrator waiting for queued tasks.

Resource Utilization

CPU utilization averages 0.65% with no spikes recorded. Memory consumption is 144MB out of 914MB available (roughly 16% utilization), well within normal bounds. Disk usage is 6.2GB of 39GB (17%), leaving ample headroom for logs and temporary files. AWS Lightsail status checks show zero failures in the last 2 hours, confirming network connectivity and underlying hypervisor health.

Session Activity and Turn Limits

Over the 24-hour period, three separate agent sessions were initiated:

  • Session 1 (00:00 UTC): Exited with code 1 after reaching the 30-turn limit imposed by the Claude API. No error—this is a designed constraint.
  • Session 2 (00:02 UTC): Completed successfully. The session processed e-signature and crew page blockers, creating a "needs-you" task for manual intervention. This session did not hit the turn limit.
  • Session 3 (00:05 UTC): Again exited with code 1 at 30 turns. No new tasks were queued afterward; the daemon resumed normal idle polling.

The turn limit exits are not crashes or failures—they're logged as exit code 1 because the session terminated before task completion. This is a known architectural constraint: the Claude API enforces a conversation turn limit per session. When a complex task requires more than 30 exchanges between the agent and the model, the session exhausts its budget and the daemon stops gracefully, queuing any incomplete work for the next session.

Critical Issue: OAuth Token Failure in port_sheet_sync

The Problem

The port_sheet_sync.py script, which synchronizes port sheet data to Google Sheets via the Google Sheets API, has been failing every 30 minutes with the same error:

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

This indicates the stored Google OAuth refresh token has expired or been revoked. Port sheet syncs have not successfully executed since at least yesterday afternoon. Any changes to port data are not being reflected in the Google Sheets backend.

Why This Happened

Google OAuth tokens have a limited lifetime. Refresh tokens can be revoked if:

  • The user changed their Google account password
  • The user explicitly revoked OAuth consent for the application
  • The token was not refreshed within a 6-month window (Gmail-specific policies)
  • The OAuth credentials (client ID/secret pair) were rotated

The Fix

The auth_ga.py script in /Users/cb/Documents/repos/tools/ contains reusable OAuth authentication logic. This script was designed to handle Google API authentication with interactive browser-based consent flow. For port_sheet_sync.py, the token must be re-authenticated using the same mechanism, and the new token stored in the secrets directory referenced by the sync script's configuration.

The re-authentication should be done locally, not on the instance, to ensure the user can complete the browser-based OAuth consent flow. Once the new token is generated and stored, it should be committed to the secure secrets store and deployed to the Lightsail instance via your normal deployment pipeline.

Infrastructure and Deployment Context

During this development session, multiple sites and services were modified:

  • 86from.com: A site directory was renamed from 86dfrom.com to 86from.com, deployed to S3, and CloudFront cache was invalidated. A new SEO page (what-does-86d-mean) was created.
  • sailjada.com: The main index.html received 20+ iterative edits, primarily fixing a booking widget JavaScript issue involving malformed template literals (double braces {{ and }} appearing outside the widget's expected scope).
  • queenofsandiego.com: The BookingAutomation.gs Google Apps Script file was edited twice, likely for booking flow improvements.
  • auth_ga.py: The Google Analytics authentication utility was created and edited, and now serves as the foundation for re-authenticating the port_sheet_sync token.

Key Decisions and Architecture Patterns

SSH Access via Systems Manager

When the local jada-key private key was not found, we opted for AWS Systems Manager Session Manager rather than uploading keys. This approach avoids storing private keys locally and leverages IAM role-based permissions already configured on the instance. The Lightsail API was used as a fallback to fetch temporary SSH credentials for direct connection when needed.

Handling the Turn Limit Constraint

The 30-turn limit is a Claude API constraint, not a bug. The daemon handles it gracefully by exiting with a logged error and re-queuing incomplete tasks. However, this suggests that future architectural decisions should consider:

  • Breaking complex tasks into smaller, turn-efficient subtasks
  • Implementing task decomposition logic in the daemon's task queue manager
  • Potentially requesting a higher turn limit from Anthropic for production workloads

Centralized OAuth Token Management

The auth_ga.py script demonstrates the value of centralized authentication logic. Rather than embedding OAuth flows in individual sync scripts, a shared utility reduces code duplication and ensures consistent token refresh handling across all Google API consumers.

What's Next

  • Re-authenticate Google OAuth for port_sheet