Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Diagnosing and Staging a Critical Deposit Funnel Outage: Apps Script Access Control & Endpoint Routing

Executive Summary

A silent but total failure in the deposit reservation system affected 11 event pages across sailjada.com and queenofsandiego.com. The root cause: two Google Apps Script deployments returning 403 (access denied) and 404 (not found) errors on their /exec endpoints, which power the "Reserve" widget across all public event pages. This post covers the diagnostic approach, staging of the fix, and the infrastructure changes required to restore the booking funnel.

What Was Done

Problem Statement

All reservation buttons across 11 event pages silently failed to submit deposits. Users could click "Reserve," but the backend call to the Apps Script endpoint returned error responses. Since the funnel was dark (no error logging visible to end users), inbound bookings were being dropped with no visibility into revenue impact.

Affected pages:

  • sailjada.com/events/* (10 charter event pages)
  • queenofsandiego.com/book-a-charter (1 booking page)

Symptom: HTTP 403 and 404 on Apps Script endpoints; no new deposits in transaction logs.

Root Cause Analysis

Traced the issue to two Google Apps Script deployments with broken access control:

  • Main endpoint (10 pages): https://script.google.com/macros/s/AKfycbw.../44Pme8wCA/exec returning 403 Forbidden — deployment exists but "Who has access" is not set to "Anyone"
  • Worship endpoint (1 page): https://script.google.com/macros/s/AKfycbw.../AFsLWaO3/exec returning 404 Not Found — deployment has been deleted or never redeployed after a code change

The project ID (1dDpSK8JZda7XUpKIGlyyAX19KLL4JqFjYVtpcunB5ZE3-NMX_9v0lQJ5) was correct, but the deployments controlling the /exec URLs were misconfigured.

Technical Details

Diagnostic Steps

Step 1: Locate all Apps Script references

grep -r "script.google.com/macros" ~/Documents/repos/sites/queenofsandiego.com/
grep -r "AKfycbw" ~/Documents/repos/sites/queenofsandiego.com/event-templates/

Found two distinct endpoint patterns in the S3-backed event page sources.

Step 2: Test endpoints live

curl -i https://script.google.com/macros/s/AKfycbw.../44Pme8wCA/exec \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"action":"test"}'

Confirmed 403 and 404 responses in both cases.

Step 3: Verify project exists and locate deployments

Accessed script.google.com → Project Settings → copied Project ID → confirmed it matches the source code repo records in /jada-ops/DEPOSIT-OUTAGE-FIX-2026-06-02.md.

Step 4: Inspect deployment configuration

In the Apps Script console: Deploy → Manage deployments

  • Main deployment: exists, but "Who has access" was restricted (not "Anyone")
  • Worship deployment: missing — likely rolled back or deleted after last code push without a new deployment

Why This Happened

Google Apps Script deployments require explicit access control. Even if the project code is public, the deployment's execution permissions must be set to "Anyone" for unauthenticated web calls to succeed. The 403 indicates the deployment was either created with restricted access or a redeploy changed the settings. The 404 indicates the worship endpoint was either never redeployed after a code change, or the deployment was manually deleted.

Infrastructure & Fix

Staged Fix (Not Yet Applied)

The fix involves two steps, both in the Google Apps Script console (no code changes):

  1. Main endpoint redeploy:
    • Go to Deploy → Manage deployments
    • Select the main deployment (UUID ending in 44Pme8wCA)
    • Click Edit access
    • Set Who has access to "Anyone"
    • Set Execute as to "Me" (the Apps Script owner account)
    • Click Deploy
  2. Worship endpoint redeploy:
    • Same steps, but for the worship deployment (UUID ending in AFsLWaO3)
    • If the deployment is truly deleted, create a new one from the existing code

Why "Execute as Me": This ensures the Apps Script runs with the owner account's permissions (e.g., access to the Google Sheet backing the reservations). Unauthenticated callers can invoke the endpoint, but the script itself runs with the owner's credentials.

Why Not Redeploy from Source?

We use clasp (Google Apps Script CLI) for version control, but the fix requires only a permission change on the existing deployment, not a code push. Redeploying from source would introduce unnecessary change risk and require local clasp setup. The faster path is a one-click permission fix in the console.

Event Page Source Updates

Once the endpoints are live and responding 200 OK, we verify all event pages are calling the correct URLs. The endpoint URLs are hardcoded in the S3-backed HTML/JS:

/Documents/repos/sites/queenofsandiego.com/src/event-pages/charter-{event-id}.html
/Documents/repos/sites/queenofsandiego.com/src/event-pages/worship-{event-id}.html

A dry-run endpoint rewrite command confirmed the URLs are correct in the source. After the fix is applied, we sync the source to S3 and verify CloudFront serves the new endpoints live.

Key Decisions

  • Console fix over code redeploy: Faster, lower-risk, and the issue is permissions, not code.
  • "Anyone" + "Execute as Me" pattern: Allows public access while maintaining the script's ability to read/write the backing data store.
  • Dual-endpoint strategy: Two separate Apps Script projects handle charters vs. worship events. Allows independent scaling and failure isolation.