Error Tracking¶
Conflux reports uncaught exceptions to Sentry via sentry/sentry-laravel. Sentry is scoped to error capture only — performance tracing is handled by OpenTelemetry (see Tracing) and deliberately left disabled in Sentry to avoid two SDKs instrumenting the same spans. See ADR-0034 for the rationale.
Configuration¶
| Key | Env var | Purpose |
|---|---|---|
dsn |
SENTRY_LARAVEL_DSN |
Sentry project DSN. Exception reporting is a no-op when unset. |
traces_sample_rate |
SENTRY_TRACES_SAMPLE_RATE |
Left null (disabled) — OpenTelemetry is the tracer of record. |
profiles_sample_rate |
SENTRY_PROFILES_SAMPLE_RATE |
Left null (disabled), for the same reason. |
Full option list: config/sentry.php.
Context enrichment¶
Every reported exception is tagged with the acting principal, so issues can be filtered and triaged by who was affected:
| Trigger | Sentry user | Tags |
|---|---|---|
API request authenticated via the connection guard |
id = the SystemConnection UUID |
connection_id; tenant_id (when the connection has one — connections can be tenant-less pre-assignment) |
Admin-panel request authenticated as a User |
id, email |
— |
| No authenticated request (queue job, scheduled command, CLI) | — | — |
Scope limitations¶
Context enrichment covers HTTP-triggered exceptions only — both the admin panel and the API. Queue-worker and console exceptions are still reported to Sentry, but with no user or tag attached, since there is no request or authenticated actor to attribute them to.
Implementation¶
| Class | Responsibility |
|---|---|
App\Exceptions\SentryContext |
Registers a reportable() callback that enriches the Sentry scope with the acting SystemConnection/tenant_id or admin User, ahead of Sentry's own exception handler |
bootstrap/app.php |
Wires SentryContext::register() and Sentry\Laravel\Integration::handles() into withExceptions(), alongside App\Exceptions\ApiProblemRenderer |