Sulu Messenger Failed Queue Bundle Laravel Package

Product Decisions This Supports

• Failure-handling strategy for async workloads. Informs whether to adopt an existing failed-message queue (with retry/delete UI) versus building custom retry/DLQ tooling around Symfony Messenger — reducing bespoke infrastructure and ops burden.
• Runtime upgrade planning. The 1.2.0 release adds PHP 8.4 support, which unblocks teams planning a PHP 8.4 migration on Sulu/Symfony stacks that rely on Messenger for background processing.
• Build vs. buy for operational tooling. Provides a ready-made admin surface for inspecting, retrying, and purging failed messages, so this is a candidate to replace internal "failed jobs" dashboards or manual DB surgery.
• Platform coherence. Signals whether the Sulu ecosystem (CMS + Messenger + queue tooling) is a viable long-term platform choice versus assembling separate pieces.
• Release cadence signal. A minor release driven by PHP version compatibility (with a new external contributor) is a positive maintenance health indicator for a small package — relevant to dependency risk scoring.

When to Consider This Package

Consider it when:

• You are running Sulu CMS (Symfony-based) and use Symfony Messenger for asynchronous processing.
• You need a failed-message queue with an admin UI for retry/delete, rather than CLI-only failure handling.
• You are planning a PHP 8.4 upgrade and need dependencies that keep pace.
• You want a maintained, drop-in bundle rather than maintaining fork of failed-queue plumbing yourself.

Look elsewhere when:

• You are on a Laravel-first stack — Laravel's queue:failed / Horizon cover this space; this bundle is not a Laravel package despite being a "PHP package" in the dependency graph.
• You need a framework-agnostic failed-queue solution, or you are not using Sulu's admin integration (much of the package's value is the Sulu UI).
• You require a large, active community or long-term commercial support — this is a small, single-maintainer-org project (PHPro), so vendor support should not be assumed.
• You need advanced features (rate-limited retries, cross-transport DLQ federation, deep observability/metrics) that are not in this bundle's scope.

How to Pitch It (Stakeholders)

For executives / product leadership: This is a small, actively maintained open-source bundle that gives our async background processing a safe failure path — failed jobs can be inspected and retried from the admin rather than silently lost. The 1.2.0 release confirms active maintenance and PHP 8.4 readiness, so it does not block our runtime upgrade roadmap. Cost is effectively zero; risk is low but concentrated in a small maintainer base.

For engineering: The bundle integrates Sulu admin with Symfony Messenger's failure transport, providing a UI to retry/delete failed messages. 1.2.0 is a compatibility bump (PHP 8.4) plus a new external contributor — no breaking changes. Caveats: it is Sulu-specific, not Laravel; if our stack isn't Sulu, equivalent Laravel tooling (Horizon / queue:failed) is the better fit. Pin the version, watch upstream release cadence, and avoid coupling core business logic to the package's UI — the persistent failure transport is the durable contract, the admin surface is convenience.