Sentry Bundle Laravel Package

Getting Started

Treat this as a legacy-only integration for Symfony 2 / early Symfony 3 applications. It is not a good choice for new projects; the modern replacement is the Sentry Monolog handler / sentry/sentry-symfony.

Minimal path:

1. Check composer.json constraints first. Confirm the bundle, raven/raven, and your Symfony version are mutually compatible.
2. Enable the bundle in app/AppKernel.php:

   new Kunstmaan\SentryBundle\KunstmaanSentryBundle(),
   

3. Configure the Sentry DSN in the appropriate environment config, usually production only:

   # app/config/config_prod.yml
   kunstmaan_sentry:
       dsn: "%sentry_dsn%"
   

   Use a parameter or environment variable rather than hard-coding the DSN.
4. Clear the cache and trigger an uncaught exception in the environment where the bundle is enabled. Confirm the event appears in Sentry with the expected environment/release metadata.

Where to look first:

• README.md for the supported Symfony/raven versions.
• DependencyInjection/Configuration.php for the real config keys.
• Resources/config/services.xml / .yml for the client service ID and listener wiring.
• The bundle’s exception listener / kernel event subscriber, because that is what auto-reports uncaught exceptions.

First practical use case: production uncaught-exception reporting. The bundle’s main value is that it autoloads an exception handler/listener, so existing controllers and services do not need modification just to get fatal/uncaught errors into Sentry.

Implementation Patterns

Let uncaught exceptions flow. Do not wrap every controller action in try/catch just to report to Sentry. Normal Symfony exceptions should bubble to the kernel exception listener, which the bundle hooks into. Catch only where you can recover or add domain context.

Report handled exceptions deliberately. For exceptions you catch and swallow, inject the bundle’s Raven client service and capture explicitly. Confirm the service ID in the bundle config; commonly it is something like kunstmaan_sentry.client:

try {
    $this->paymentGateway->charge($order);
} catch (GatewayException $e) {
    $this->get('kunstmaan_sentry.client')->captureException($e);
    // recover or rethrow
}

Add request/domain context early. Raven supports user, tags, and extra context. Set user context after authentication and add tenant/request identifiers so events are searchable:

$client = $this->get('kunstmaan_sentry.client');
$client->user_context(['id' => $user->getId(), 'email' => $user->getEmail()]);
$client->tags_context(['tenant' => $tenant->getSlug()]);
$client->extra_context(['order_id' => $order->getId()]);

Keep this in a request listener or a small service rather than scattering it across controllers.

Use environment and release metadata. Configure environment, release, and possibly tags from parameters so production, staging, and deploy versions are distinguishable in Sentry. This is one of the highest-value day-to-day settings.

Handle console separately. The Symfony kernel exception listener covers HTTP requests. Long-running or cron commands may need explicit capture around command execution, or a console event listener that reports exceptions. Do not assume CLI failures are automatically visible.

Avoid duplicate reporting. If Monolog is also configured to send to Sentry, or if you add a second Sentry listener, the same exception can produce multiple events. Pick one primary exception-reporting path: either this bundle’s autoloaded handler or a Monolog handler.

Filter expected noise. 404s, validation failures, auth failures, and known business exceptions should usually be excluded or downgraded. Use the bundle’s config options or a custom listener/processor to filter before sending.

Integration tip: keep Sentry enabled only in production/staging. In dev and test, disable the DSN or use a null transport so local errors and test failures do not pollute the project.

Gotchas and Tips

• Deprecated status is the biggest gotcha. Do not build new infrastructure on this bundle. Plan migration to sentry/sentry-symfony or a Monolog Sentry handler. The longer a legacy app stays on raven-php, the harder the eventual SDK upgrade becomes.
• Old SDK, old PHP. raven-php predates the modern Sentry PHP SDK. Expect incompatibilities with PHP 7.4+/8.x, modern Symfony, and current Sentry features such as tracing, breadcrumbs improvements, and modern sampling controls.
• Config keys are version-sensitive. Always inspect Configuration.php and the bundle’s service definitions rather than copying config from blog posts. The service ID and available options may differ between tagged releases.
• Autoloaded exception handling can conflict with Symfony’s Debug component. In dev, Symfony’s error handler and the bundle’s handler may both be active. If events are missing or duplicated, check which exception handler is registered first.
• Fatal errors and shutdown errors are not always captured. Raven’s handler covers exceptions, but fatal PHP errors, memory exhaustion, and some shutdown failures may need separate handling or may be lost.
• Synchronous sending can add latency. If the client sends during the request, error paths can become slower. Prefer asynchronous transport where supported, or ensure Sentry outages do not take down the app.
• DSN mistakes fail quietly. A malformed DSN or blocked outbound network often means no events and no obvious application error. Verify with a deliberate test exception and check Sentry’s ingestion logs.
• Cache clearing matters. Symfony caches container config. After changing DSN, environment, or bundle registration, clear the cache for the target environment.
• Do not report from tests. Disable the bundle in test or inject a no-op client. Otherwise test suites can generate real Sentry events and slow down CI.
• Extension points: use a custom kernel exception listener, Raven processors, or Monolog handlers for filtering/enrichment. But keep enrichment small and defensive; an exception inside the Sentry reporting path should never break the original request.
• Migration tip: inventory what you actually use from this bundle — uncaught exception capture, manual captureException, user context, tags. Those map cleanly to the modern Sentry Symfony SDK or Monolog handler, often with less custom wiring.