Delayed Event Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for domain-event plumbing. This package addresses a real, recurring failure mode: side effects (emails, webhooks, queue dispatches, search indexing, audit logs) firing before Doctrine's transaction commits, so users get notified about records that later roll back. That problem is worth solving; whether this package is the solution is a separate question.
• Platform-fit triage. Despite being filed under a Laravel/PHP package request, this is a Symfony bundle built around Doctrine ORM's postFlush event — not Eloquent, not Laravel. If our stack is Laravel, this is a non-starter and should be closed out of the evaluation backlog rather than carried.
• Roadmap input for event-driven architecture. If we're maturing toward domain events / transactional outbox patterns, this is a useful reference implementation for the "collect during flush, dispatch after commit" mechanic — worth an hour of engineering reading, not a procurement decision.
• Use-case scoping. Legitimate fits are notification fan-out after persistence, audit trail emission, cache invalidation, and post-commit job dispatch. It is not a durability guarantee — it does not give at-least-once delivery, retries, or an outbox table, so it should not be pitched as solving reliable messaging.

When to Consider This Package

Adopt only if all of the following hold: we are on Symfony with Doctrine ORM; we need post-flush dispatch and nothing more; we accept the dependency is effectively unmaintained (single star, zero dependents, last release February 2022, no evidence of ongoing support); and we are prepared to vendor or fork it.

Look elsewhere — or build in-house — when:

• The stack is Laravel/Eloquent. Disqualifying; the abstraction doesn't map.
• Supply-chain hygiene matters. One star, zero dependents, and a three-year-old last release mean no security surface review, no CVE response, and no community backstop. For anything customer-facing, that's a no.
• We need delivery guarantees. This is in-process event dispatch after commit, not a transactional outbox. If the process dies post-commit, the event is gone.
• We need async, multi-datasource, or non-Doctrine support.

Realistically, the pattern is 50–100 lines of code: listen to postFlush, drain a collected event list through the dispatcher. The recommendation is to reimplement internally and keep ownership.

How to Pitch It (Stakeholders)

To executives: We evaluated a package that fixes a specific class of embarrassing bug — telling a customer their order shipped, or firing a webhook, for a record that was subsequently rolled back. The problem is real and worth fixing. The package itself is not the answer: it's a near-abandoned, single-maintainer Symfony component with no adoption, it doesn't apply to our Laravel stack, and it's small enough that our own engineers can reproduce the behavior in roughly a day with full test coverage and no external dependency. Net recommendation: fix the problem, skip the dependency. Cost is minimal; the risk of taking the dependency is not.

To engineering: It's a Symfony bundle that hooks Doctrine's postFlush and replays collected events through the Symfony event dispatcher so side effects only fire after commit. Useful as a design reference. We should implement the equivalent ourselves — it's a small listener plus a collector service, it lets us control ordering and error handling, and it avoids pinning us to an unmaintained package last released in 2022. If we want durability beyond "after commit," we should scope a proper transactional outbox on the roadmap instead.