Add local dev Sentry DSN support and fix environment tag for test vs. production
Continuous Integration / config (pull_request) Successful in 9s
Continuous Integration / prepare (pull_request) Successful in 1m13s
Continuous Integration / build (pull_request) Successful in 1m57s
Continuous Integration / test (pull_request) Successful in 1m47s
Continuous Integration / deploy-test (pull_request) Skipped
Continuous Integration / config (pull_request) Successful in 9s
Continuous Integration / prepare (pull_request) Successful in 1m13s
Continuous Integration / build (pull_request) Successful in 1m57s
Continuous Integration / test (pull_request) Successful in 1m47s
Continuous Integration / deploy-test (pull_request) Skipped
Co-authored-by: Junie <junie@jetbrains.com>
This commit is contained in:
@@ -492,3 +492,27 @@
|
||||
**Context**: Post-workflow follow-up (feature already marked Complete); continues the `feature/sentry_error_logging` branch. `pnpm run build`, `pnpm run lint` (0 errors, pre-existing-style warnings only) and `pnpm run test` (16/16 tests) all succeeded. Changes not yet committed/pushed.
|
||||
|
||||
---
|
||||
|
||||
## Post-Completion Follow-up: Local Development Sentry DSN Added
|
||||
|
||||
**Timestamp**: 2026-07-25T14:48:00Z
|
||||
|
||||
**User Input**: "Kunnen we voor lokaal development ook een DSN toevoegen? Kan dat eventueel in een lokale environment file of iets?" (with a Sentry DSN value provided).
|
||||
|
||||
**AI Response**: "Added a `.env.local` file containing the user-provided `VITE_SENTRY_DSN` for local development (`pnpm dev`) — already covered by the existing `.gitignore` `*.local` rule, so it is never committed. Added a committed `.env.example` template (empty `VITE_SENTRY_DSN` value) documenting how to set this up for other/future contributors. Updated `monitoring-setup.md` with a new bullet explaining the local-DSN workflow and recommending a separate Sentry project/DSN for local development so its noise doesn't mix with the test-environment data."
|
||||
|
||||
**Context**: Post-workflow follow-up (feature already marked Complete); continues the `feature/sentry_error_logging` branch. No code logic changes — only local-only config and documentation.
|
||||
|
||||
---
|
||||
|
||||
## Post-Completion Follow-up: Sentry `environment` Tag Fixed to Distinguish Test vs. Production
|
||||
|
||||
**Timestamp**: 2026-07-25T14:52:00Z
|
||||
|
||||
**User Input**: "Volgens mij hadden we iets van een onderscheiding tussen de test en productie-omgevingen. Is dat ook met de development-omgeving?"
|
||||
|
||||
**AI Response**: "Identified a real gap: `environment: import.meta.env.MODE` correctly reports `'development'` for `pnpm dev`, but both the test build and any future production build run via `vite build` without an explicit mode, so `MODE` is always `'production'` for both — meaning Sentry would currently tag test-environment events as `'production'`, indistinguishable from real production. Fixed by changing `environment` to `import.meta.env.VITE_APP_ENV ?? import.meta.env.MODE` in `src/main.tsx`: this uses the already-existing `VITE_APP_ENV` build-time variable (`'test'`/`'production'`) when set, falling back to `MODE` only for local development where `VITE_APP_ENV` is unset. Updated `monitoring-setup.md` to describe this corrected behavior."
|
||||
|
||||
**Context**: Post-workflow follow-up (feature already marked Complete); continues the `feature/sentry_error_logging` branch. Build/lint/test re-verified after the change.
|
||||
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user