Production Issues Ai Gograb Space Analysis

Documentation for Sessions

Production Issues Analysis: ai.gograb.space/dashboard

Date: 2026-03-12
Session: 213
Status: Analysis Complete

Executive Summary

The production app at https://ai.gograb.space/dashboard exhibits three distinct issue categories:

  1. MIME type errors (service-worker.js, chunk JS files) — Certain root cause
  2. WebSocket malformed URLs (wss://https/socket.io/) — Likely config/construction bug
  3. 401 Unauthorized / Login failed — Likely auth flow or backend

Issue 1: MIME Type Errors (Certain)

Symptoms

Root Cause

Two contributing factors:

A. Overly aggressive _redirects rule

/*  /index.html  200

Per Cloudflare Pages docs:

"Redirects are always followed, regardless of whether or not an asset matches the incoming request."

The /* rule matches every request (including /service-worker.js, /main-*.js, /src-*.js) and rewrites it to /index.html. The browser receives HTML with Content-Type: text/html instead of JavaScript, causing MIME type errors.

B. Service worker not built before deploy

deployment/cloudflare/deploy-ai.sh runs only nx build, not nx build-full or nx build-sw:

yarn nx build $NX_NAME --configuration=production --skip-nx-cache

The build-sw target (which produces service-worker.js) is never executed. Even if the redirect were fixed, /service-worker.js would 404 because the file is never built.

Fix (Issue 1)

  1. Remove or replace the catch-all redirect — Use 404.html fallback instead:

    • Remove /* /index.html 200 from _redirects
    • Add index.html as 404.html in the build output so Cloudflare serves it for non-existent routes (SPA client-side routing)
    • Static assets (.js, .css, etc.) will then be served correctly when they exist

  2. Include service worker in deploy — Update deploy-ai.sh to run nx build-full or add nx build-sw gograb-ai after the main build so service-worker.js is present in the output.

Issue 2: WebSocket Malformed URL (Likely)

Symptoms

The host is https instead of ai-api.gograb.space — the URL is malformed.

Root Cause (Speculative)

Socket.IO clients receive a base URL that is either:

Relevant code:

Production environment.prod.ts has:

These should produce valid Socket.IO URLs. The wss://https/ pattern suggests a bug in URL construction or in a library that receives the wrong base URL.

Fix (Issue 2)

  1. Add logging in production (or temporary) to log the exact URL passed to each io() call.
  2. Search for any place that passes path, host, or url incorrectly to Socket.IO.
  3. Ensure no code passes a full URL where Socket.IO expects only host/path, or vice versa.

Issue 3: 401 Unauthorized / Login Failed (Likely)

Symptoms

Root Cause (Speculative)

Fix (Issue 3)

  1. Verify credentials and auth flow in production.
  2. Check backend-ai-api and backend-api logs for 401s.
  3. Confirm CORS and auth headers for ai.gograb.space and ai-api.gograb.space.

Recommended Action Order

Priority Action Impact
1 Fix _redirects (remove catch-all, add 404.html) Unblocks JS loading and SW registration
2 Add build-sw to deploy-ai.sh Enables service worker when redirect is fixed
3 Debug WebSocket URL construction Restores real-time features
4 Investigate 401/auth Restores login and protected features

References