Weave Code
Deferred Event Bundle Laravel Package
fervo/deferred-event-bundle
DeferredEventBundle for Symfony queues domain events during a request or transaction and dispatches them at a controlled later point, so listeners and side effects run after persistence completes and stay consistent with committed data.
fervo/deferred-event-bundle defers Symfony event dispatching until after the database transaction commits or the response is sent—so listeners never fire for rolled-back work and side effects don't slow down requests.
Queue domain events during a request and release them automatically, keeping controllers fast and event-driven work (emails, webhooks, indexing) safe.
- Deferred dispatch after commit or kernel.terminate
- Simple API to queue events
- No listeners for rolled-back transactions
- Native Symfony DI and configuration
- Pluggable release strategies
Frequently asked questions about Deferred Event Bundle
- Is fervo/deferred-event-bundle a Laravel package?
- No. It is a Symfony bundle that registers through Symfony's Kernel, bundle system, DI container compiler passes, and EventDispatcher. Laravel has no bundle-registration mechanism, so Composer can install the code but nothing will wire it up. Treat it as a pattern to borrow rather than a dependency to add to a Laravel application.
- Can I install fervo/deferred-event-bundle with Composer in a Laravel project?
- Composer may install it if the constraints resolve, but installation is not integration. There is no Laravel service provider, facade, or config publishing, and the deferral hooks into Symfony's dispatcher rather than Laravel's event dispatcher contract. Expect it to sit inert in vendor/ unless you rewrite it as a Laravel package.
- What does fervo/deferred-event-bundle actually do?
- It queues domain events and dispatches them only after your unit of work commits, so listeners do not fire on rolled-back data. Under the hood it depends on FastCGI's fastcgi_finish_request() to hand work to a post-response phase. That prevents listeners from running against uncommitted data but also ties the mechanism to PHP-FPM and FastCGI runtimes.
- Which Laravel versions does fervo/deferred-event-bundle support?
- None officially. The last release was January 2016, and its Composer constraints target PHP 5.5/7.0-era and Symfony 2.x/3.x. It will not install cleanly on PHP 8.2+ or modern Laravel without a maintained fork and updated constraints.
- What is the Laravel equivalent of deferred events after a transaction commits?
- Laravel provides dispatchAfterResponse() for post-response jobs and events, the defer() helper and deferred callbacks in Laravel 11+, and ShouldQueue on listeners for durable async processing. Combine database transaction callbacks such as DB::afterCommit() with dispatchAfterResponse() or queued listeners to avoid firing on rolled-back data. These native primitives cover the bundle's value proposition and are actively maintained.
- Does fervo/deferred-event-bundle work with Laravel Octane, Swoole, or RoadRunner?
- No. The deferral mechanism relies on fastcgi_finish_request(), which only exists under PHP-FPM and FastCGI. Under CLI workers, Octane on Swoole or RoadRunner, or Apache mod_php, the deferral silently degrades or is unavailable entirely. That runtime constraint is the real integration risk, not the bundle code.
- Does deferred event dispatch guarantee delivery or retries?
- No. Post-response deferral is fire-and-forget: there is no durability, no retry policy, no dead-letter queue, and no ordering guarantee. If the process dies mid-work, the event is lost silently. The same PHP-FPM worker also stays occupied until the deferred work completes, so heavy deferred work consumes a worker slot and taxes throughput.
- Is fervo/deferred-event-bundle maintained or production safe?
- It is abandoned, with the last release in January 2016, roughly a decade stale. It has 43 stars and zero dependents, so there is no downstream proof it works on modern PHP or Symfony. Adopting it means forking, bumping PHP and Symfony constraints, fixing type errors, and replacing deprecated Symfony 2 event-dispatcher APIs.
- How do I migrate a Symfony app that uses this bundle to Laravel?
- Do not port the bundle. Extract the behavior instead: a service provider, an event subscriber that checks runtime capability, and an adapter that calls fastcgi_finish_request() or defer() when available and falls back to dispatch() on a queue. If a legacy Symfony service already uses it, leave it in place and wall it off; start new Laravel work on native primitives.
- How do I build a deferred event pattern in Laravel without this package?
- Build a thin internal package in roughly one to two weeks: a service provider, a subscriber that checks whether the runtime supports post-response work, and an adapter that uses defer() or dispatchAfterResponse() when possible and a queued listener otherwise. Prototype against dispatchAfterResponse() and a ShouldQueue listener behind the same interface, then benchmark latency and worker utilization. Keep Horizon for queue scaling and observability so you retain a durable path.
Weaver
How can I help you explore Laravel packages today?