Raygun Bundle Laravel Package

Getting Started

First, read the repo before installing. This is a Symfony2 bundle (not a Laravel package), zero stars, zero dependents, unmaintained. Open composer.json and DependencyInjection/Configuration.php first — they define the supported Symfony/PHP constraints and the real config keys (api_key, enabled, environment) faster than any README. Assume nothing works until you've smoke-tested it.

The single most important check before you spend time: confirm your framework. If you're on Laravel, stop — you cannot composer require this. The bundle constrains symfony/framework-bundle ~2.x, which hard-conflicts with the Symfony components Laravel ships (^6.x/^7.x), and Laravel has no bundle system (Bundle subclass, DependencyInjection/*Extension, kernel.exception listener don't map to service providers). The only durable asset is the pattern: wrapping raygun4php in a listener. Write that adapter fresh rather than reverse-engineering an abandoned bundle.

Minimal adoption path if you are genuinely on Symfony 2 (maintenance mode only):

1. Pin the version explicitly — there will be no bugfix releases:

   composer require "onceit/raygun-bundle:~1.0"
   

2. Register the bundle in app/AppKernel.php, only in environments where you want reports (keep dev/test out to protect your Raygun quota and avoid noise):

   if (in_array($this->getEnvironment(), ['prod', 'staging'])) {
       $bundles[] = new Onceit\RaygunBundle\OnceitRaygunBundle();
   }
   

3. Configure the key in app/config/config.yml, matching whatever the Configuration class expects (commonly onceit_raygun: { api_key: ... }). Put the real value in parameters.yml/env, never committed YAML:

   onceit_raygun:
       api_key: "%raygun_api_key%"
       enabled: true
   

4. First use case — prove the wiring end to end: throw a deliberate exception from a staging controller, hit the route, and confirm the report lands in Raygun with the right environment/tag. That one test validates the listener, the key, and outbound HTTP simultaneously.

If that smoke test fails and you can't fix it in ~30 minutes, stop. Wiring raygun4php into a small kernel.exception listener (or a Laravel ErrorReporter service behind an interface) is less code than debugging an abandoned bundle.

Implementation Patterns

Environment-scoped config. Use Symfony's config layering so dev reports nothing and prod reports everything. Keep %raygun_api_key% as an empty placeholder in parameters.yml.dist and let CI/deploy inject the real value. This is the cheapest safety valve you have.

Listener by default; manual client only for handled errors. The bundle earns its keep by auto-reporting uncaught exceptions. For caught exceptions you actually care about (failed payment, third-party API failure), inject the client service and report explicitly — then re-throw or log so nothing is swallowed:

try {
    $gateway->charge($order);
} catch (GatewayException $e) {
    $this->raygun->sendException($e); // exact method depends on the bundled client version
    $this->logger->error('Charge failed', ['exception' => $e]);
    throw new PaymentFailedException('Payment failed', 0, $e);
}

Tag every report with release + environment. Grouping and "did this regress?" are only useful if reports carry a version. If the bundle doesn't expose tags, set them on the client service at container build time via a small compiler pass or a setParameter-driven service definition. Without this you get one undifferentiated blob of errors across releases.

Pick the bundle listener or a Monolog Raygun handler — never both. Running both produces duplicate reports for every exception and wrecks your counts and quota. The listener catches fatals via Symfony's error handler; a Monolog handler gives finer control over levels/context. Choose deliberately and disable the other.

Filter expected control-flow exceptions at the source. Add an ignore list for NotFoundHttpException, AccessDeniedHttpException (bots), validation failures, and similar — otherwise your dashboard drowns in noise and you miss the real errors. Doing this in the app beats trying to filter in the dashboard after the fact.

On Laravel (the honest path): build a thin adapter behind an interface so Raygun is swappable. Singleton-bind raygun4php in a service provider, call it from App\Exceptions\Handler::report(), and add a Monolog handler for non-exception errors:

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

This single abstraction is the highest-value decision given vendor uncertainty and is a day's work — versus permanently owning a fork.

Gotchas and Tips

It will not install in a modern Laravel or Symfony 4/5/6/7 app. The symfony/framework-bundle ~2.x constraint and bundle conventions are hard stops. Symfony2 reached EOL in 2018. If you need Raygun, use the official raygun4php SDK and write the ~100-line adapter; do not force this bundle in.

Treat it as fork-and-own code. Zero upstream means every patch is yours to write, review, and re-audit forever. Vendor it (composer repositories or a path repo), pin the commit, and own the patches. An abandoned package handling exception payloads (PII, session IDs, internal hostnames) is a recurring SCA/compliance finding — budget for it explicitly.

Never report synchronously on the request path. A blocking HTTP post per exception adds tail latency and, during an error storm, can cascade — reporting failures must never fail the user's request. Mitigate with a queue/async path, client-side sampling, fingerprint-based deduplication, a circuit breaker on repeated send failures, and hard timeouts.

Watch dependency conflict. raygun4php pulls Guzzle/PSR versions that may conflict with what your app already uses. Check composer why-not before assuming the install is clean.

Beware silent failure. A misconfigured key or a backed-up queue means you believe you have observability and have none. Send a synthetic startup/health event and alert on the absence of events — that gap is the one that bites during incidents.

Configure payload limits and PII redaction explicitly. Do not trust defaults for scrubbing request bodies, headers, or query strings; Raygun quota and data-handling rules both punish unfiltered payloads.

Confirm the vendor before writing the adapter. If Raygun isn't a settled commercial decision, evaluate Sentry or Bugsnag first — both are Laravel-native and maintained, and either removes this integration problem (and this bundle) entirely.