fix(compose): point mana-auth SYNC_DATABASE_URL at mana_sync, not mana_platform

`sync_changes` lives in DB `mana_sync` (the dedicated sync engine
database), not in `mana_platform` where mana-auth's other queries land.
The compose env had this miswired since SYNC_DATABASE_URL was first
introduced — F4's bootstrapUserSingletons (`c07db300b`) ran into
"relation sync_changes does not exist" but its fire-and-forget caller
swallowed the failure silently.

Punkt 3's explicit `/api/v1/me/bootstrap-singletons` endpoint
(`099cac4a0`) surfaced the misconfig as a user-visible 500 on first
real boot, which is how it got caught.

This also unbreaks user-data.ts (GDPR data summary entity counts +
account deletion's sync-row cleanup) which was returning 0 / no-op
for the same reason.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Till JS 2026-04-27 15:26:13 +02:00
parent de2134fb02
commit 5f15946776

View file

@ -268,7 +268,13 @@ services:
MANA_SERVICE_KEY: ${MANA_SERVICE_KEY}
MANA_CREDITS_URL: http://mana-credits:3061
MANA_SUBSCRIPTIONS_URL: http://mana-subscriptions:3063
SYNC_DATABASE_URL: postgresql://postgres:${POSTGRES_PASSWORD:-mana123}@postgres:5432/mana_platform
# Points at the mana-sync DB where sync_changes lives — read by
# the F4 bootstrap, the /api/v1/me/bootstrap-singletons endpoint,
# and the GDPR data summary in user-data.ts. Previously pointed
# at mana_platform which silently broke all three (F4 was
# fire-and-forget so the error went unnoticed; the explicit
# endpoint added in 099cac4a0 surfaced it as a 500).
SYNC_DATABASE_URL: postgresql://postgres:${POSTGRES_PASSWORD:-mana123}@postgres:5432/mana_sync
BETTER_AUTH_SECRET: ${BETTER_AUTH_SECRET:-${JWT_SECRET:-your-jwt-secret-change-me}}
# KEK for the encryption-vault feature (Phase 9). Required in production
# — generate with `openssl rand -base64 32`. See services/mana-auth/CLAUDE.md.