Sulu Messenger Failed Queue Bundle Laravel Package

Product Decisions This Supports

• Failed-message visibility and recovery for Symfony Messenger: This bundle adds a failed-queue capability to Messenger-backed workflows inside a Sulu CMS application, letting teams inspect, retry, or discard messages that failed during async processing. It directly supports reliability and operational-tooling decisions for any product surface dependending on background jobs (imports, indexing, notifications, media processing).
• Build vs. buy for admin-facing queue tooling: Instead of building a bespoke "failed jobs" screen and storage layer into a Sulu admin, teams can adopt this bundle to get that capability faster. This is the core build-vs-buy trade-off to weigh.
• Roadmap dependency assessment for Sulu/Symfony stacks: If the product runs on Sulu CMS, this becomes a candidate dependency for operational resilience features. If the product is Laravel- or plain Symfony-based, it is largely out of scope — the Sulu and Jackalope/PHPCR coupling is a real signal.
• Operational maturity decisions: A failed-queue UI/retry mechanism reduces mean time to recovery and lowers the need for manual DB forensics when async work breaks — directly relevant to SLA and on-call burden.
• Maintenance-risk budgeting: The 0.4.1 release is a pure dependency bump (jackalope-doctrine-dbal), reinforcing that this is a young (0.x) package with maintenance activity but limited feature velocity. That informs whether to treat it as a strategic dependency or a tactical add-on.

When to Consider This Package

Consider it when:

• Your application is built on Sulu CMS and uses Symfony Messenger for asynchronous processing.
• You need operator-facing failed-message management (inspect, retry, purge) without engineering a custom admin UI.
• You want to avoid maintaining bespoke Doctrine-backed failure storage and Sulu admin wiring.
• You're comfortable adopting a 0.x package and pinning versions / accepting occasional breaking changes.

Look elsewhere when:

• You are on Laravel — Laravel already ships failed_jobs infrastructure and Horizon/queue tooling; this bundle's Sulu/PHPCR coupling makes it a poor fit.
• You are on plain Symfony without Sulu — the Sulu admin integration is the main value, and you'd be pulling in CMS baggage.
• You need a stable, GA-level dependency with a compatibility guarantee; 0.x plus a dependency-only patch release signals early-stage maturity.
• Your failed-message needs are already met by native Messenger transports, dead-letter queues, or dedicated observability tooling.

How to Pitch It (Stakeholders)

To executives: This is a small, targeted add-on for teams running Sulu CMS that makes background job failures visible and recoverable from the admin. It reduces operational firefighting and shortens recovery time when async processing breaks — without a custom build. It is early-stage (0.x), so treat it as a tactical reliability tool rather than a long-term platform commitment.

To engineering: It gives you a managed failed-queue for Symfony Messenger inside Sulu, including retry/purge from the admin, backed by Doctrine. The trade-offs are the Sulu + Jackalope/PHPCR coupling and pre-1.0 versioning — the 0.4.1 release was a dependency bump only, so expect modest feature cadence. Pin versions, review changelogs on each bump, and avoid it if you're not on Sulu.