Rollbar Php Symfony Bundle Laravel Package

Getting Started

Know what this is first: rollbar/rollbar-php-symfony-bundle is a Symfony bundle, not a Laravel package. It has no service provider, no facade, no auto-discovery. If you're working day-to-day in Laravel, the realistic path is one of:

• Use rollbar/rollbar-php (the client this bundle wraps) directly, wired up in AppServiceProvider / bootstrap/app.php, or
• Use a Laravel-specific community package, or
• Install this bundle only if you're maintaining a Symfony app or a hybrid/lumen-style service that already uses Symfony components.

If you do install it (Symfony context):

composer require rollbar/rollbar-php-symfony-bundle

Then, first place to look is the bundle's README and DependencyInjection/Configuration.php — that file is the authoritative list of every config key, not the docs.

Minimal config (config/packages/rollbar.yaml):

rollbar:
    access_token: '%env(ROLLBAR_ACCESS_TOKEN)%'
    environment: '%kernel.environment%'
    enabled: true

First use case: wire up exception reporting in staging/production, keep it disabled locally. The bundle registers a kernel exception listener that ships uncaught exceptions to Rollbar automatically — you should see your first error in the dashboard within minutes of throwing a 500.

For Laravel specifically, the equivalent "first use case" with the raw client is:

// bootstrap/app.php or a service provider
Rollbar::init([
    'access_token' => config('services.rollbar.token'),
    'environment'  => app()->environment(),
    'root'         => base_path(),
]);

Implementation Patterns

1. Config-driven environment separation Keep the token and environment in env vars, never in the committed YAML. Because enabled is a separate key from access_token, you can ship a token everywhere and only flip enabled: '%env(bool:ROLLBAR_ENABLED)%' — this avoids the "forgot to remove the token" problem and keeps a single config file.

2. Automatic vs. manual reporting Let the built-in exception listener handle uncaught exceptions (the 80% case). Reserve manual reporting for caught-and-swallowed errors and business-logic anomalies:

use Rollbar\Rollbar;
use Rollbar\Payload\Level;

Rollbar::report_message('Payment reconciliation mismatch', Level::warning(), [
    'order_id' => $order->id,
    'expected' => $expected,
    'actual'   => $actual,
]);

If you're on the Symfony bundle, inject the rollbar service rather than calling the static Rollbar:: facade — static calls bypass the container config and are a common source of "why is my environment wrong" bugs.

3. Exception → context enrichment The single highest-value pattern is attaching request/user context to every report. In a Symfony setup this means a listener on kernel.exception at a priority below the bundle's listener, so you can decorate before the payload is built. In Laravel, do it once in App\Exceptions\Handler::report() or via Rollbar::configure() with a person callback.

4. Log handler integration Route Monolog's error and above to Rollbar and leave debug/info on files. Duplicating everything is the fastest way to burn through your event quota and drown the dashboard.

5. Deployment/version tagging Stamp code_version (git SHA or release tag) into the config at deploy time. Rollbar's "first seen in version" and regression detection are useless without it. Combined with v5.1.0's new framework/framework-version metadata, you can now slice errors by Symfony version in the dashboard — genuinely helpful when you're running a gradual PHP/Symfony upgrade across a fleet.

6. Rollbar v4 client support (new in 5.1.0) If you're already pinning rollbar/rollbar-php:^4, this release means you no longer need a replace/conflict hack in composer.json. Verify your composer.lock actually resolves to v4 and check the client's changelog for renamed config keys — the v3→v4 jump touched payload/serializer internals more than the public API.

Gotchas and Tips

It is not a Laravel package. No RollbarServiceProvider, no config/rollbar.php, no php artisan vendor:publish. Anything you find online titled "Rollbar for Laravel" that references this repo is describing the Symfony bundle; the Laravel integration is a different package or hand-rolled.

Static vs. container instance. Rollbar::init() is global state. Calling it twice (once in a provider, once via the bundle) silently overwrites config. Pick one entry point and grep for Rollbar::init before debugging anything weird.

.env parsing of booleans. '%env(ROLLBAR_ENABLED)%' yields the string "false", which is truthy in PHP. Use '%env(bool:ROLLBAR_ENABLED)%' or you will ship errors from your local machine to production for a week.

The "works locally, silent in prod" failure mode. This is almost always: (a) enabled false, (b) token from the wrong env, or (c) the client failing to transmit and swallowing the error. Set the Rollbar logger to a Monolog channel and check it before assuming the app is error-free.

Scrubbing PII. Rollbar ships request params and headers by default. Add scrub_fields for password, token, authorization, cookie, and anything domain-specific (SSNs, card last-4) before the first production deploy, not after. Retrofitting means deleting already-ingested payloads.

Sampling, not filtering. Under volume, use exception_sample_rates / sample_rate per exception class rather than dropping classes wholesale — you want to keep the low-volume, high-severity signals at 100%.

Performance. The client buffers and flushes at request end. If you're in a queue worker or a long-running Octane/Swoole process, the per-request assumption breaks: the buffer never flushes or grows unbounded. Explicitly flush on job completion and in a terminate/middleware hook.

Extension points are lean. The bundle exposes the rollbar service and its exception listener; there's no rich plugin API. Real customization happens either by decorating the service or by using the underlying rollbar/rollbar-php hooks (Rollbar::configure() with person_fn, custom Payload transformers). Don't expect to extend the bundle itself without forking.

PHP 8.2 / CI note. v5.1.0 adds PHP 8.2 test coverage but this is a test-matrix addition, not a hard requirement change — check the composer.json php constraint before assuming you can drop 8.0/8.1 support.