Raygun Bundle Laravel Package

Technical Evaluation

Architecture fit: none for Laravel. Despite cataloguing as a Laravel/PHP package, this is a Symfony2 bundle — a Bundle subclass with DependencyInjection/*Extension, Resources/config/services.yml, and a kernel.exception listener. Laravel has no bundle system; it uses service providers, a single Illuminate\Foundation\Exceptions\Handler, and container bindings. The bundle's symfony/framework-bundle ~2.x constraint hard-conflicts with the Symfony components Laravel ships (^6/^7). It cannot be installed into a modern Laravel app without a fork-and-rewrite.

Integration feasibility: low as published, high as a pattern. The only transferable asset is the idea: wire the framework-agnostic raygun4php SDK into the exception pipeline. That is roughly a 100-line adapter — one service provider, one singleton binding, one report() call, one Monolog channel. Reverse-engineering that from an abandoned Symfony2 bundle costs more than writing it fresh.

Technical risk: high.

• Abandonment: Symfony2 reached EOL in 2018; last activity predates that. No releases, no security response, no CVE triage.
• Adoption signal: 0 stars, 0 dependents, score 0.03 — no production usage anywhere, so no community bug surface has been exercised.
• Supply chain: abandoned transitive Guzzle/PSR dependencies are a standing SCA finding; Raygun's API has moved on since this wrapper was written.
• Licensing is the one clean element: MIT, permissive, commercially compatible.

Key questions for the TPM to resolve before any engineering spend:

1. Is Raygun a selected vendor or exploratory? If exploratory, the comparison set is Sentry (sentry/sentry-laravel), Bugsnag, Rollbar, Flare — all maintained and Laravel-native.
2. What PHP/Laravel versions are in scope, and is Octane in use?
3. Is the requirement crash reporting only, or APM/performance too? Raygun spans both; alternatives differ in strength.
4. Does procurement/security require a vendor-supported integration, or is an in-house adapter acceptable?
5. Who owns the code long-term if we fork the bundle — and is that owner identified before we adopt?

Integration Approach

Stack fit. Do not adopt the bundle. Treat it as prior art. The viable path is a thin first-party adapter over raygun4php, or a maintained third-party package.

Recommended migration path.

1. Vendor decision first. Confirm Raygun commercially before writing code. Engineering sunk into an adapter for a vendor later dropped is the main avoidable cost.
2. Build the adapter, don't port the bundle. Register raygun4php as a singleton in a service provider, inject it into App\Exceptions\Handler::report() or a dedicated reporting listener, and add a Monolog handler for non-exception errors.
3. Abstract behind an ErrorReporter interface so Raygun is swappable for Sentry/Bugsnag without touching call sites. This is the highest-value design decision given vendor uncertainty.
4. Decommission legacy bundle usage in any surviving Symfony2 app as a separately scoped workstream — not bundled into this effort.

Compatibility notes.

• Check raygun4php's Guzzle constraint against the app's existing Guzzle version.
• Laravel 11 changed the exception handler contract (closures vs. render/report overrides); verify against the target version.
• Under Octane the client must not be a request-scoped singleton holding stale state — resolve per report or reset per request.
• Never call the Raygun API synchronously on the request path.

Sequencing. Vendor decision → adapter POC in staging (1–2 days) → sampling/quota configuration → production canary → 30-day cost and signal-quality review → decide whether to keep the in-house adapter or migrate to an official package.

Operational Impact

Maintenance. The bundle is a permanent liability: zero upstream means any fork becomes your code to own, patch, and re-audit indefinitely — for functionality that is a day's work. The adapter approach caps that liability at a small, well-understood surface. Either way, budget the ownership explicitly; "no one owns it" is how these integrations rot.

Support. None. No maintainer, no issue triage, no security advisories. An abandoned package handling exception payloads — which routinely contain PII, session identifiers, and internal hostnames — is a compliance conversation you will eventually have to have. Log-scrubbing and a data-handling review are mandatory regardless of vendor.

Scaling and failure modes.

• Synchronous posts to Raygun on every exception add tail latency and, under an error storm, can cascade: reporting failures must never fail the request.
• Mitigations: async via queue, client-side sampling/rate limiting, deduplication by fingerprint, circuit breaker on repeated send failures, hard timeouts.
• Quota overages are a real cost risk during incidents — the moment you most need telemetry is the moment you blow the plan limit. Set sampling before the canary.
• Silent failure is the subtle one: a misconfigured API key or a backed-up queue means you believe you have observability and have none. Add a synthetic/health-check event and alert on absence of events, not just on errors.
• Payload size limits and PII redaction need explicit configuration, not defaults.

Ramp-up. Writing the adapter is low-effort for any mid-level PHP engineer familiar with Laravel's container and exception handler — about a day, plus a day of testing. Ramp-up on the abandoned Symfony2 bundle is effectively total: a new engineer must learn a dead framework's bundle conventions to maintain code nobody else uses. That asymmetry alone justifies skipping it.

TPM recommendation. Reject onceit/raygun-bundle on framework incompatibility and abandonment. If Raygun is the chosen vendor, fund a small in-house adapter over raygun4php behind an ErrorReporter interface; run it as a two-week spike with a 30-day signal-quality review. If the vendor is not yet decided, evaluate Sentry or Bugsnag first — both are Laravel-native and maintained, and either removes this integration problem entirely.