Weave Code
Worker Message Failed Event Bundle Laravel Package
smartassert/worker-message-failed-event-bundle
Symfony bundle that dispatches a worker message failed event, letting applications react to failed worker messages with logging, retries, alerts, or custom failure handling.
Symfony bundle for handling exceptions encapsulated within a WorkerMessageFailedEvent
Frequently asked questions about Worker Message Failed Event Bundle
- Can I use smartassert/worker-message-failed-event-bundle in a Laravel application?
- No. This is a Symfony bundle that hooks Symfony Messenger's WorkerMessageFailedEvent, which is a different event model from Laravel's queue failure path. Laravel fires Illuminate\Queue\Events\JobFailed, so the bundle will not register or run in a Laravel app without adopting Symfony Messenger. If you are on Laravel, treat this as a reference implementation to study or fork rather than something to install.
- How do I install and enable this bundle in a Symfony project?
- Install it with Composer and register it in config/bundles.php, then add any bundle configuration the package ships with. The real prerequisite is that symfony/messenger is installed and that worker failure events are actually firing in your runtime. Run a composer why-not check against your pinned Symfony and PHP versions before committing to it.
- What exactly does the bundle do when a worker message fails?
- It listens for Symfony Messenger's WorkerMessageFailedEvent, which fires when a message fails or exhausts its retries during handling. The name and vendor suggest it reports or annotates those failures somewhere, likely a SmartAssert backend, but the exact behavior is not documented in the package overview. Confirm whether it logs, sends an HTTP report, annotates, or triggers retries before relying on it.
- Which Symfony Messenger and PHP versions are supported?
- Version constraints are not spelled out in the available information, so check the composer.json on the repository and run composer why-not against your platform. Pin both symfony/messenger and your PHP minor version, and validate against your project's Symfony LTS rather than the latest release. Also verify the 2025-12-01 release date; if it is future-dated or a pre-release, assume there is no production track record.
- Does it separate retryable failures from terminal failures?
- It is unclear from the overview whether the bundle inspects the willRetry flag on WorkerMessageFailedEvent or treats every failure the same. That distinction matters a lot: alerting on every retry attempt produces noise, while only alerting on terminal failures can hide repeated transient problems. Test both scenarios in a non-production environment before wiring it into on-call alerting.
- Is an external SmartAssert service or API key required?
- Probably. The package name implies it reports failures to a SmartAssert service, which likely means an endpoint, credentials, and an expected payload schema. That downstream contract, not the PHP code, is the main integration risk. Validate the emitted payload against the sink's schema before enabling it anywhere real.
- Does it block the worker if the failure sink is unreachable?
- This is not documented, and it is the question to answer first. If reporting runs synchronously on the worker thread, an unreachable sink can add latency or stall message processing entirely. Test with the sink deliberately down to see whether the bundle fails open by dropping the signal or fails closed by blocking the worker.
- What exception or PII data leaves my application?
- If the bundle reports failures to an external service, exception messages, stack traces, and message payloads may be transmitted. Those often contain user data, tokens, or internal hostnames, so review exactly what is serialized and where it is sent. Confirm retention and redaction behavior before enabling it on queues that carry sensitive payloads.
- How should I test and roll this out safely in production?
- Start with a non-production spike that confirms failure events fire and payloads look correct, then validate the payload against the sink's expected schema. Run it in shadow mode in staging alongside your existing alerting so you can diff coverage and false-positive rates. Enable it per-transport or per-queue, smallest blast radius first, behind environment-scoped config that can be disabled without a redeploy, and document rollback as config disable plus composer remove.
- Is the package maintained, and what are the alternatives?
- Adoption signals are weak: zero stars, zero dependents, a single vendor organization, and effectively no community support channel. Treat it as vendor-owned code with a bus factor of one, assign an internal owner, and assume you may need to fork it, which the MIT license permits. For Laravel, the practical alternative is a listener on JobFailed plus your existing monitoring such as Horizon, Sentry, or a custom alerting job; for Symfony, a small custom listener on WorkerMessageFailedEvent gives you the same behavior with full control.
Weaver
How can I help you explore Laravel packages today?