Bugfix: Why is backend-api (api.gograb.space) returning 404 on all r...

Documentation for Sessions

🐛 Bugfix: Why is backend-api (api.gograb.space) returning 404 on all r...

Date: 2026-02-09
Time: 17:44:34 UTC
Session: gspace1-101.2
Agent: backend
Confidence: 98%
Status: ✅ Documented

📋 Decision Context

Question:

Why is backend-api (api.gograb.space) returning 404 on all routes and backend-ai-api (ai-api.gograb.space) returning 502?

Task: Fix broken Railway deployments for backend-api (404) and backend-ai-api (502)

🎯 Decision Made

Chosen:

Root cause: railway.toml on deploy/api branch was misconfigured to build backend-ai-api instead of backend-api. The deploy/ai-api branch was 77 files stale, still importing VittoModule (decoupled in Session 98).

Options Considered:

Fix only railway.toml without updating code
Full merge of session-101 into both deploy branches
Restructure deployment infrastructure to prevent recurrence

💭 Reasoning

Proof: curl api.gograb.space/ai-api/health returned service:backend-ai-api confirming the wrong binary was deployed. Both deploy branches had identical railway.toml pointing to Dockerfile.railway.backend-ai. The flat deployment/ directory with mixed configs for 4 services made this cross-contamination possible during a merge. For ai-api, the stale VittoModule's HandoffWsClient continuously retried WS connections causing error spam visible in Railway deploy logs, likely causing health check failures.

📁 Files Involved

railway.toml
deployment/Dockerfile.railway.backend
deployment/Dockerfile.railway.backend-ai
tools/scripts/deployment/lib/deployment-config.js

🔗 Related

Decision ID: dev_1770659074791_7yu5iof
Session: 101
Workspace: gspace1

Auto-generated by MCP Smart Consolidation