Messenger Retry Bundle Laravel Package

Technical Evaluation

Framing note: Despite the "Laravel/PHP" classification, this is a Symfony bundle, not a Laravel package. It registers into the Symfony kernel's bundle system and hooks the Messenger middleware pipeline. Laravel has no bundle registry and its queue system is a separate implementation (jobs/failed_jobs, --tries, backoff(), retryUntil()). The single most important TPM finding is that the overlap with Laravel is conceptual, not technical.

Architecture fit

• The package is a thin policy layer over symfony/messenger: it contributes a middleware into the bus pipeline and lets you declare retry strategy per transport or per message class, with exponential backoff and hand-off to a failure transport on exhaustion. Architecturally sound and idiomatic — it extends Messenger rather than replacing it.
• Critical overlap risk: Symfony Messenger already ships a retry strategy (framework.messenger.transports.<name>.retry_strategy with max_retries, delay, multiplier, max_delay) plus failure-transport support. The bundle's genuine differentiator is per-message granularity and zero-boilerplate config. Everything else may be reproducible with core config. This must be validated before any adoption decision, because adopting a third-party middleware to duplicate core behaviour adds supply-chain risk for no capability gain.
• For a Laravel-only estate: fit is poor. You cannot install a bundle into Laravel's container without Symfony's kernel/bundle machinery. A hybrid app running standalone symfony/messenger inside Laravel is possible but you would wire the middleware manually — i.e., depend on the package's internals while discarding its bundle packaging. That is a fork in all but name.
• Zero stars, single-vendor origin (PcComponentes, a Spanish e-commerce retailer) suggests an internally-extracted bundle open-sourced as a by-product. Expect bus-factor 1–2 and documentation calibrated for people who already know the internal codebase.

Integration feasibility

• High for a Symfony 6.4/7.x application already using Messenger with a real transport and a failure transport.
• Low-to-zero for a Laravel application. The realistic Laravel plays are: (a) do not adopt — use Laravel's native tries/backoff and a failed_jobs monitoring path; (b) treat the repo as a reference design for implementing per-job retry policy in Laravel; (c) adopt only if you already run Symfony Messenger inside Laravel and accept manual wiring.
• The v2.1.1 "Symfony 7 support" line is a constraint widening shipped as a patch. Backward-compatible in principle, but it means a floating composer update can resolve a new major Symfony line. Pin it.

Technical risk

• Double-retry amplification (high, if misconfigured). If the core transport retry_strategy is left enabled alongside this bundle's policy, a message can be retried by both layers — effectively max_retries² attempts. This is the failure mode most likely to reach production.
• Non-idempotent handler replay (high). Retries re-execute the handler. Without idempotency keys or deduplication, backoff + retry converts a transient failure into duplicated side effects (charges, emails, inventory decrements). This is a product risk, not a library risk, and the library does not mitigate it.
• Unverified compatibility claim (moderate). "Symfony 7 support" may mean "constraint widened and installs" rather than "CI matrix green on 7.x." No CI evidence was supplied.
• Semantic-versioning ambiguity (moderate). A major-framework ceiling expansion released as a patch signals the project treats framework compatibility as non-breaking.
• Abandonment / single-maintainer (moderate-high). Zero stars, no community, no published support policy. If the vendor's internal needs diverge from yours, you inherit the code.
• Operational coupling (moderate). The bundle assumes a failure transport exists and is consumed. An unconsumed failure transport is a silent message graveyard.

Key questions for the maintainer

1. What does this provide that Symfony's native retry_strategy (with multiplier/max_delay) plus RecoverableMessageInterface does not — specifically, is per-message retry policy the only differentiated capability?
2. Does the middleware replace or compose with the core RetryStrategy? What happens if both are configured?
3. Is the retry delay implemented as a re-queue (release to transport) or an in-process sleep? In-process sleeps hold workers and distort capacity planning.
4. Is Symfony 7.x in the CI matrix with a green suite, and which Laravel/standalone-Messenger combinations are officially supported?
5. What is the retry-attempt counter's durability across worker restarts, and how does it interact with messenger:failed:retry and --no-retry?
6. Is there a documented support policy and a stated commitment horizon from the vendor?

Integration Approach

Stack fit

• Confirm the target before anything else: Symfony 6.4 or 7.x + symfony/messenger + a durable transport (AMQP, Redis, Doctrine) + a configured failure transport. If that is not the stack, stop — the package is not applicable.
• For a Laravel-primary estate, record the decision as "not adopted; Laravel native queue retry covers the requirement," and capture the bundle's policy model as an input to future design. That is a legitimate and often correct outcome.

Migration path

1. Inventory existing retry behaviour: which transports have retry_strategy configured, what max_retries/delay/multiplier values are in play, and which handlers are non-idempotent.
2. Disable the core transport retry_strategy on any transport you hand to the bundle, to prevent double-retry amplification. This is a hard prerequisite, not a recommendation.
3. Introduce the bundle's policy on one low-risk transport (e.g., notifications/email) rather than the highest-volume or financially-material queue.
4. Map the old numeric retry counts to the bundle's backoff curve explicitly, and document the resulting worst-case redelivery window per message type.
5. Only after that transport is stable, extend to others — one transport per change window.
6. If a Laravel hybrid is genuinely in scope, spike the manual middleware registration first and treat the spike as a go/no-go gate, not a formality.

Compatibility

• Verify the package's symfony/messenger constraint against your pinned version, and check MiddlewareInterface signature compatibility across the 6.4/7.x boundary (return types were tightened in the 6→7 transition).
• Run composer update --dry-run on a scratch branch and read the resolved diff — the risk is not this package failing but this package forcing a resolver decision that moves symfony/* underneath other dependencies.
• Validate the failure transport contract end-to-end in staging: a message that exhausts retries must land in the failure transport, be visible to operators, and be replayable.

Sequencing Spike → single transport → observability (retry counters, failure-transport depth alerts) → progressive rollout → decommission any now-redundant core retry_strategy config. Keep the lockfile committed and review composer.lock diffs in PRs.

Operational Impact

Maintenance

• Nominal code maintenance: this is config-plus-middleware, no host code changes expected.
• Real obligation is dependency custody: pin the version (do not float a patch that can pull a new Symfony major), track whether the maintainer keeps CI green, and maintain an internal fork contingency. With zero stars and a single vendor, assume you may own this code within 12–24 months.

Support

• No SLA, no vendor accountability, thin documentation. Publish an internal supported-versions statement derived from your own validation, not from the changelog.
• Escalation path is GitHub issues to a small team with their own priorities. If retries sit on a revenue-critical path, budget for the fork.

Scaling

• Retries are a load multiplier: worst-case broker throughput is base_rate × (1 + max_retries). Size queues and workers against the retry ceiling, not the happy path.
• Long backoff windows mean messages sit in the transport; ensure retention/TTL exceeds the maximum backoff so messages are not expired mid-retry (a silent-loss mode).
• Failure-transport depth grows with traffic and with any systemic failure. It needs alerting, a retention policy, and a replay runbook — otherwise it becomes an unbounded DLQ.
• The bundle adds no meaningful runtime overhead per message; the cost is entirely in retry volume and worker occupancy.

Failure modes

• Double-retry amplification — core retry_strategy plus bundle policy yields multiplicative attempts and a retry storm. Mitigation: disable core retry on governed transports; assert this in config review.
• Duplicate side effects — non-idempotent handlers re-executed on redelivery. Mitigation: idempotency keys, outbox pattern, or handler-level dedupe. This is the highest-severity product risk.
• Poison-message loop — a permanently failing message retries to exhaustion, consuming worker capacity on every attempt. Mitigation: low max_retries for validation-class exceptions, fast-fail classification.
• Silent DLQ accumulation — failure transport unwatched; messages effectively lost. Mitigation: alert on depth > 0 and a weekly triage owner.
• Config drift — per-message policies proliferate and nobody knows the effective policy for a given message. Mitigation: policy-as-code review, a single source of truth, and a documented matrix of message → retry policy.
• False Symfony 7 support claim — installs but breaks on an untested component. Mitigation: host application's own suite plus staging smoke tests, not the changelog.

Ramp-up

• Low for a team already fluent in Symfony Messenger: roughly 1–3 engineer-days including the spike, config migration, and a staging cycle.
• The expensive knowledge is not the package — it is retry semantics, idempotency design, and failure-transport operations. Budget for that explicitly; a team that adopts the bundle without it will ship duplicate side effects.
• TPM cost: one short maintainer exchange to resolve the Key Questions, plus a written decision record stating why this was or was not adopted relative to Symfony's native retry strategy.