mirror of
https://github.com/ever-co/ever-gauzy.git
synced 2026-10-02 01:54:50 +08:00
Ruslan KonviserandClaude Opus 5.5
69a293175a
The whole ever-co Sentry organisation (5,000 errors a month on the current plan) has accepted no error after the first hours of each monthly reset: 2026-07-09, 08-09 and 09-09 are the only days with accepted errors in 90 days. About 97% of what was accepted were info-level log lines, not errors. - SentryService (the API's Nest logger) turned every log/warn/debug/verbose call into its own Sentry event and ignored the `logLevels: ['error']` the API passes. It now honours `logLevels`: listed levels become events, the rest become breadcrumbs on the next event. An unset or empty list keeps the old capture-everything behaviour. The API reads the list from SENTRY_LOG_LEVELS (default `error`), so capturing warnings or logs again is a config change. - RequestContextMiddleware logged the start and end of every request, including the Kubernetes readiness probe on /api/health every 10 s on every pod: 2 events per probe, ~2,900 events an hour from the four Ever Teams API pods alone. /api/health and /api/health/* are no longer logged. This is decided by path only, since a client-set User-Agent must not be able to hide other requests. - apps/api/src/sentry.ts printed the DSN at startup and ran the SDK in debug mode in production (`environment.production` is false in the published image), writing several SDK lines per request. Debug is now opt-in with SENTRY_DEBUG=true, and the DSN is no longer printed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>