Sentry Symfony Laravel Package

Technical Evaluation

Architecture fit — mismatch, and it fails silently. gcg-it/sentry-symfony is a Symfony bundle. It registers via config/bundles.php, wires services through DI compiler passes, and hooks Symfony's HTTP kernel event lifecycle (kernel.request, kernel.exception, kernel.terminate). Laravel has no bundle system — it uses service providers, facades, and a middleware pipeline. Laravel does consume low-level symfony/* components transitively, but the Symfony HTTP kernel and its dispatcher never run inside a Laravel request, so the package's automatic exception capture, breadcrumbs, and request-scoped context never fire. For an observability dependency, silent non-capture is the worst possible failure: the team believes it has coverage and finds out during an incident.

Integration feasibility — installable, not usable. Composer will likely resolve it (Laravel already pulls symfony/*), but there is no service provider, no publishable config, no facade, and no middleware to register. You would hand-wire Sentry\Client/Hub yourself — at which point the correct dependency is the base sentry/sentry SDK, or ideally sentry/sentry-laravel. symfony/* constraints may also collide with the versions each laravel/framework major pins.

Technical risk — high, and not just technical. Zero stars, zero dependents, and a one-line description copied from the upstream tagline indicate an unreviewed agency fork of the official sentry/sentry-symfony bundle. Observability packages sit on the hot path of every request and routinely capture request bodies, headers, and breadcrumbs — an unreviewed fork is an unreviewed PII and supply-chain surface. There is no evidence of a patch cadence or upstream security backports, so internal dependency-risk review should assume no maintainer until proven otherwise.

Key questions for the vendor/maintainer:

1. Which upstream sentry/sentry-symfony branch and version is this forked from, and what exactly changed?
2. What is the supported PHP / Symfony / Sentry SDK version matrix, and when was the last release?
3. Is this intended for Laravel at all, or is it published for internal Symfony projects?
4. Is there any reason not to use sentry/sentry-laravel (Laravel) or the official sentry/sentry-symfony (Symfony)?
5. What is the deprecation plan, and who owns patching it?

Verdict: reject for Laravel adoption. The defensible dependency is sentry/sentry-laravel.

Integration Approach

Stack fit. For Laravel 9/10/11, sentry/sentry-laravel is the only justifiable choice: service provider, facade, exception-handler hook, queue/console/scheduler instrumentation, Octane awareness, and Laravel-version-tagged releases. This package provides none of that and adds a Symfony-only surface the team would have to own.

Migration path. For a hybrid estate (legacy Symfony service + Laravel app), split the dependency per application rather than forcing one package to serve both:

• Laravel services → sentry/sentry-laravel
• Symfony services → official sentry/sentry-symfony
• Shared conventions: consistent DSN, environment, release (git SHA), and traces_sample_rate so events correlate across services. If a team has already forked this package for a local Symfony patch, the migration target is to rebase that patch onto the official bundle and let the fork die.

Compatibility. Confirm the Sentry PHP SDK major (v3 vs v4 has breaking Hub/Scope changes), a PHP 8.1+ baseline, and that symfony/* constraints do not collide with the laravel/framework major in use. Run composer why-not before any install.

Sequencing.

1. Define the observability goal: error capture only, or errors + performance tracing + release health.
2. Adopt the official SDK per framework; set SENTRY_LARAVEL_DSN/SENTRY_DSN via environment, never committed.
3. Instrument the Laravel exception handler, queue workers, scheduler, and console kernel; verify with a deliberately thrown test exception in staging.
4. Add release tagging in CI and source-map/artifact upload if a frontend exists.
5. Establish alert routing, ownership, and a triage runbook before enabling tracing at volume.
6. Only then evaluate whether a Symfony component in the estate needs the official bundle.

Operational Impact

Maintenance. Treat this package as abandoned. No stars, no dependents, and no visible release cadence mean the effective maintainer is whoever installed it. Any upstream CVE or SDK compatibility fix in sentry/sentry-symfony will not arrive here without a manual rebase.

Support. No vendor SLA, no community, no documentation beyond upstream's Symfony-centric docs — which will actively mislead a Laravel engineer. Internal escalation has nowhere to go.

Scaling. SDK overhead is modest and sampling-driven, but two things bite at volume: event quota (an unbounded traces_sample_rate or high-cardinality breadcrumbs will burn the plan quickly) and transport mode. Ensure the async/HTTP transport is configured so a Sentry outage cannot add latency to request handling; a synchronous, un-timed-out transport is a self-inflicted availability risk.

Failure modes — ranked.

1. Silent non-capture. The bundle never boots under Laravel; the team believes it has error visibility and discovers otherwise during an incident. This is the dominant risk.
2. Composer resolution failure against laravel/framework's pinned symfony/* versions, surfacing as a blocked dependency upgrade later.
3. PII leakage via request bodies, headers, and breadcrumbs captured by default; requires explicit before_send scrubbing.
4. Recursive capture if the Sentry client throws inside the exception path.
5. Missing/invalid DSN no-ops silently in production if config is not validated at boot.

Ramp-up. Effectively infinite for the Laravel team: engineers would need Symfony bundle internals to debug why events are missing, and that knowledge has no reuse elsewhere in the stack. The equivalent effort on sentry/sentry-laravel is a half-day of configuration plus a runbook.

Recommendation. Do not adopt. Standardize on sentry/sentry-laravel for Laravel services and the official sentry/sentry-symfony for any Symfony services. If this package appears transitively in the tree, trace the dependency path and remove it.