Event Machine Laravel Package

Product Decisions This Supports

• Whether to adopt or upgrade a Laravel-native state machine package for timer-driven workflows such as trial expiry, SLA deadlines, order expiration, retry windows, and recurring machine actions.
• Build vs. buy: the package can save time on state modeling and timer handling, but adoption should include budget for scheduler configuration, CI validation, monitoring, and upgrade runbooks — not just library integration.
• Release strategy: 9.21.0 is a material corrective release. From 9.3.0 through 9.20.0, timer sweeps registered with MachineTimer::register() did not actually run from the scheduler, and failures were silent. Any product behavior depending on after/every timers during that window should be treated as potentially incorrect.
• Upgrade planning: 9.21.0 makes timers run, which can release a backlog. On first sweeps, every overdue after timer fires regardless of age; overdue every timers fire once. Product must decide whether stale timer events should still act; if not, move instances out of the timer state before deploying.
• Quality gate: add php artisan machine:validate --all to CI. It now fails when a timer machine has no runnable machine:process-timers sweep scheduled, or when the class is unquoted. Expect CI to fail on upgrade for timer machines missing from routes/console.php — those are timers that have never fired.
• Operational roadmap: plan for backlog drain at timers.batch_size (default 100) per timer per sweep, and add monitoring around the first post-upgrade sweeps rather than assuming the scheduler is healthy.

When to Consider This Package

• Consider it when you are building a Laravel application that genuinely needs state machines with after/every timers, and your team can own explicit scheduler registration, deploy validation, and post-deploy monitoring.
• Consider it if you can add and maintain MachineTimer::register() lines in routes/console.php, run machine:validate --all through artisan where routes are loaded, and tolerate manual scheduling rather than auto-registration.
• Consider it if you are already on 9.3.0–9.20.0 and depend on timers: upgrade to 9.21.0, but only with a backlog policy and a plan for stale overdue events.
• Look elsewhere or defer if you need auto-registered timer sweeps, turnkey observability, strong delivery guarantees out of the box, or cannot tolerate a mass firing of overdue timer events after deploy.
• Look elsewhere if the team cannot audit timer-driven product behavior or cannot coordinate moving instances out of timer states before upgrade. The silent-failure history raises the bar for operational discipline.

How to Pitch It (Stakeholders)

• Executives: This release fixes a serious silent failure: timer sweeps had not run from the scheduler since 9.3.0, so time-based state transitions may not have happened. Upgrading restores intended behavior, but it can release a backlog of overdue events. Treat it as a controlled migration, not a routine patch.
• Engineering: Upgrade to 9.21.0, verify every MachineTimer::register() sweep is present in routes/console.php, run machine:validate --all in CI, and monitor the first sweeps. The package now escapes --class, so no code change is needed on your side, but scheduling still must be explicit.
• Product and operations: Before deploy, inventory customer-facing timer actions and decide whether stale overdue after timers should execute. If not, move instances out of the timer state first. Expect backlog drain at timers.batch_size per timer per sweep.
• Build vs. buy: The package can accelerate Laravel state machine delivery, but the long silent-failure window means you must budget for scheduler observability, validation, and upgrade runbooks. Do not assume timers are auto-registered.