Php Airbrake Bundle Laravel Package

Getting Started

This bundle wires the php-airbrake client into Symfony2/3 so exception data is sent to Airbrake without hand-rolling a listener. Treat it as legacy glue: it exists to make a third-party notifier a first-class Symfony service, nothing more.

Minimal path:

1. Confirm the Symfony version first. This bundle targets Symfony 2/3-era (AppKernel, services.yml, parameters.yml). Modern Symfony (5/6/7) with config/packages/* and Symfony Flex will not autoload or configure it cleanly. If you are on Symfony 4+, this bundle is the wrong tool — plan a migration instead (see Gotchas).
2. Composer install in the legacy app: composer require briareos/php-airbrake-bundle. It depends on wasilak/php-airbrake (or similar namespace); expect old, unpinned versions that may fight with your Composer constraints.
3. Register the bundle in app/AppKernel.php:

   public function registerBundles() {
       $bundles = array(
           // ...
           new Briareos\PhpAirbrakeBundle\BriareosPhpAirbrakeBundle(),
       );
   }
   

4. Look at the bundle’s DI extension first, not the README. The authoritative source of truth for config keys is DependencyInjection/Configuration.php and DependencyInjection/*Extension.php in the vendor directory. Expect keys along the lines of api_key, environment, host, enabled, queue — but confirm the exact names before writing YAML.
5. Configure per environment. Put the API key under parameters.yml (or parameters.dist) and keep the bundle disabled in dev/test:

   # app/config/config.yml
   briareos_php_airbrake:
       api_key: "%airbrake_api_key%"
       environment: "%kernel.environment%"
       enabled: false
   

   Then override enabled: true in config_prod.yml.
6. First use case: catch uncaught exceptions in production. Check whether the bundle auto-registers a kernel.exception listener by running php app/console debug:event-dispatcher kernel.exception. If not, wire your own listener that pulls the notifier service and calls notify().

Implementation Patterns

Inject the notifier service, don’t call the static API. The whole point of the bundle is a configured service. Use constructor injection in your own services and controllers:

public function __construct(Airbrake\Client $airbrake) {
    $this->airbrake = $airbrake;
}

Verify the exact service id with php app/console container:debug | grep -i airbrake — the alias may be airbrake or briareos.php_airbrake.

Wrap the notify call to keep the notifier swappable. Because the package is unmaintained and the Airbrake API has moved on, put a thin ErrorReporter interface in front of it. When you migrate to Sentry or the modern Airbrake SDK, only one class changes:

interface ErrorReporter { public function report(\Throwable $e, array $context = []); }

Report from a kernel.exception listener, not from every controller. One listener that (a) logs, (b) optionally reports to Airbrake based on exception type, and (c) re-throws is the cleanest integration. Skip 404s and validation exceptions — reporting them burns your Airbrake quota and drowns signal.

Bridge Monolog instead of duplicating handlers. Configure Monolog for local logs, and let the Airbrake notifier handle only error/critical levels. A custom Monolog handler that delegates to the notifier service is often cleaner than having two parallel error paths.

Use queueing/async only if the client supports it. The old php-airbrake client can post synchronously inside the request — a slow Airbrake endpoint then becomes your outage time. If the bundle exposes a queue option, prefer it; otherwise keep the listener fast and wrap the notify call in a try/catch so the notifier never takes down the app.

Context is gold; log noise is not. When you call notify($exception, $context), pass user id, request id, release/version, and relevant domain keys. The Airbrake UI is only as useful as the context you attach.

Gotchas and Tips

• This is effectively an abandoned package. Zero stars, zero dependents listed, and Symfony2-era. Assume no security patches, no PHP 8 compatibility, and no adaptation to Airbrake’s newer APIs. Vendor it or fork it if you must keep it, but budget a migration.
• Airbrake’s API has changed since this client was written. The notifier endpoint/format the old php-airbrake talks may no longer match what Airbrake expects. Test end-to-end against a real Airbrake project before trusting it in prod.
• PHP version coupling. The underlying client predates PHP 7’s error/exception unification. \Throwable handling, strict_types, and deprecations from PHP 7.4/8.x will break or silently drop reports. Pin the PHP version in your legacy app if this bundle is load-bearing.
• Config keys drift between bundle versions. Do not trust a README snippet from a blog post. Read Configuration.php in the exact tagged version you installed.
• enabled: false must actually short-circuit. If the bundle still instantiates the client when disabled, you can leak API keys into dev logs or make network calls in CI. Verify by inspecting the container and watching for outbound requests in tests.
• Debugging a “report didn’t arrive” problem:
  1. container:debug the service and confirm the API key is set (don’t print it).
  2. Wrap notify() and log its return/exception — old clients often swallow HTTP errors.
  3. Check the Airbrake project’s environment filter (a mismatched environment hides reports).
  4. Curl the notifier endpoint directly to isolate network/proxy/firewall issues.
• Extension point: the bundle likely lets you override the client service or listener via container config. That is your escape hatch for adding context or switching the notifier without forking the bundle.
• Migration targets, in order of preference for a new app: native Symfony error handling + Sentry/Monolog, then the official Airbrake notifier, then a maintained fork of this bundle as a last resort. The day-to-day value of this package is small; don’t build new features on top of an unmaintained bridge.