f05165c594
The Sentry DSNs were hardcoded in journal/server.ts, planner/server.ts, and journal/app/lib/sentry.client.ts. Self-hosted instances inheriting the trails.cool flagship DSN would silently ship their errors to our Sentry account. Now each init site reads its DSN from env: - journal/server.ts: SENTRY_DSN (server runtime env) - planner/server.ts: SENTRY_DSN (server runtime env) - journal/app/lib/sentry.client.ts: VITE_SENTRY_DSN (build-time bake) The flagship DSN is kept as the fallback so the production deploy keeps reporting without an infra change — but self-hosters can: - set SENTRY_DSN=\"\" / VITE_SENTRY_DSN=\"\" to ship their own builds without Sentry, or - set SENTRY_DISABLED=true to skip init entirely at runtime, or - set SENTRY_DSN=/VITE_SENTRY_DSN= to their own DSN. Follow-up: a future PR can remove the hardcoded fallbacks once infrastructure/docker-compose.yml + the cd-apps.yml workflow are wired to pass SENTRY_DSN explicitly. That requires SOPS edits + workflow changes I want isolated from this purely-code change. Full repo: pnpm typecheck, pnpm lint, pnpm test all green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| journal | ||
| mobile | ||
| planner | ||