Messenger Bundle Laravel Package

Product Decisions This Supports

• Framework upgrade planning (Laravel 11 / Symfony 7): v4.2.1 removes a blocker where exception unwrapping broke under Symfony 7. If your roadmap includes a PHP/Laravel major upgrade this cycle, this package is now a "green" dependency rather than a risk item to sequence around.
• Error-handling and observability scope: the package sits in the exception rendering/unwrapping path, so it directly affects what your users and on-call engineers see when something fails. Decide whether differentiated error surfaces (developer-friendly vs. customer-safe) are a product feature you invest in or a commodity you accept from a library.
• Build vs. buy: exception unwrapping through Symfony's handler chain is fiddly, version-coupled plumbing with low differentiation. Strong default to buy/adopt; reserve engineering effort for the parts of your error experience that are actually product-specific (messaging, support handoff, PII redaction).
• Support matrix commitments: the tightened constraint (symfony/* ^6.4) lets you state which Laravel/PHP versions are supportable. Useful for narrowing the QA matrix and for pricing/support-tier decisions on legacy installs.
• Not a feature release: no new capabilities in the product sense — treat as maintenance. Nothing here changes user-facing behavior or creates a marketing/release-note moment.

When to Consider This Package

Adopt when:

• You're on, or moving to, Laravel 10.48+/11+ with Symfony 6.4 or 7.x — the fix and the constraint align with that target.
• You want framework-native, low-config exception presentation rather than a bespoke handler; the maintenance burden of hand-rolling unwrapping across Symfony majors is real.
• You need the error path to be predictable across Symfony versions — a patch that explicitly normalizes unwrapping behavior is a stability signal.
• You're consolidating on packages that track upstream Symfony majors promptly; the release cadence (patch on Symfony 7) suggests active maintenance.

Look elsewhere or hold when:

• You are pinned to Symfony 6.0–6.3 or an older Laravel. The new floor is 6.4 — a patch-level version bump that can still break Composer resolution on legacy branches. Audit composer.lock before rolling this in.
• Your error handling is heavily customized (custom renderers, multi-tenant error pages, strict PII scrubbing). Verify the unwrapping fix doesn't alter which exception reaches your renderer; wrapped exceptions behave differently from unwrapped ones downstream.
• You need error tracking with its own transport/backend — this is presentation-layer tooling, not an APM platform. Pair with a dedicated reporting service instead of asking this to be both.
• You're evaluating it purely as a "new feature" — there is none. If you're not blocked on Symfony 7 or exception rendering, deprioritize.

How to Pitch It (Stakeholders)

For executives: A routine patch to one of our error-handling dependencies. It resolves an incompatibility with Symfony 7 and formalizes support for Symfony 6.4+. Net effect: one fewer obstacle to the Laravel upgrade, no new functionality, no new cost. Risk is limited to the version floor — teams on older Symfony must upgrade that dependency first, which is a scheduling item, not a budget item.

For engineering: v4.2.1 fixes exception unwrapping under Symfony 7 and bumps the required Symfony to 6.4+. Adopt as part of the framework-upgrade workstream. Two things to check before merging: (1) dependency resolution on any branch still below Symfony 6.4 — this is a patch version but an effective breaking constraint; (2) regression-test any custom exception renderers, since unwrapping changes what the handler actually receives. No API changes for our own code.