Fancy Flow Php Laravel Package

Product Decisions This Supports

• Feature viability for nested iteration. A for_each executor and inline subgraph executor exist specifically so that per-item progress, per-item logs and per-item messages can be produced inside the graph rather than by looping inside one executor. Until v0.64.0 that promised value was silently undeliverable: nested runs forwarded only node-checkpoint and dropped node-status, node-message and log. Any roadmap item that assumes "users can watch each item in a batch progress" is only now actually buildable.
• Observability as a product requirement, not a nice-to-have. Checkpoints survived because they are what RESUME reads, so the durable-execution test suite stayed green while the human-facing signal was absent. That asymmetry is a useful PM lens: the package distinguishes machine-durable state from human-observable state, and you should budget for both explicitly in your own feature specs. If your UI, Slack notifier, or progress bar depends on events, that dependency is a distinct acceptance criterion from "the job completes and can be resumed."
• Build vs. buy for workflow orchestration. This is a pre-1.0 package (v0.64.0, issue numbers still in the double digits) that already carries durable resume, checkpoints, nested graph execution, and a typed event stream. Building that in-house is a multi-quarter effort with subtle correctness traps — this release is itself evidence of how subtle: two executors independently carried identical copies of a forwarding condition and were identically wrong. Centralising into RunEvent::forParent() is the kind of fix you get from a maintained dependency and rarely from a side project.
• Use cases this unlocks with confidence. Per-record enrichment/pipelines where an operator needs to see item 7 of 40 stall; inline subworkflows used as reusable steps; long-running jobs where resume-after-failure is table stakes and "why is it still running?" is the support ticket.
• Instrumentation contract decisions. Consumers must now read the event address (each/0/body, each/1/body, …) rather than assume every node-status maps to a top-level node. That is a design decision you inherit: your dashboards should be keyed on address, not on event counts.

When to Consider This Package

Adopt when:

• You are on Laravel/PHP and need durable, resumable execution — checkpoints and resume are first-class, not bolted on.
• Your workflows have nested structure (fan-out over a collection, or an inline reusable subgraph) and you need per-branch visibility, not just a final result.
• You want an event stream you can consume (node-status, node-message, log, node-checkpoint) to drive UI, alerting, or audit logs.
• You can absorb pre-1.0 churn: 0.x versioning means no semver guarantee, and this release is a semantic change to event volume even though no API signature moved.

Look elsewhere, or scope down, when:

• You need a 1.0 stability/SLA commitment or a long-term support window. v0.64.0 signals fast iteration.
• You require run-scoped lifecycle events from inside nested runs. run-start, run-end, run-error are deliberately not forwarded — a lane does not have its own lifecycle in the parent's stream. If your product needs per-item start/end notifications, derive them from node-status on the lane, or plan extra work.
• Your consumers cannot be changed to read event addresses. Any host that inferred structure from event ordering or counts will misbehave once nested events begin arriving.
• You have no nested runs and no durability requirement — you are paying complexity for capability you will not use.
• You need a hard guarantee that event shape is frozen. This fix landed because nothing asserted on human-facing events; the surrounding test discipline is still maturing.

How to Pitch It (Stakeholders)

To executives: We are evaluating a Laravel workflow engine that runs long, multi-step jobs durably — if a job fails halfway, it resumes from where it stopped instead of starting over. The v0.64.0 release fixes a real defect: work split into per-item branches could report completion to the system but not to a human, so progress bars, per-item logs, and "what is it doing right now?" visibility were silently missing — while every durability test still passed. That is a support-cost and trust issue, and it is now fixed. The caveat is maturity: this is a 0.x package, iterating quickly, and we should treat the dependency as fast-moving rather than settled.

To engineering: No code changes are required to pick up the fix, with one exception — if any consumer counts node-status events or assumes they all refer to top-level nodes, it must be updated to key on the event address (each/0/body, each/1/body, …). You will now receive node-status, node-message and log from inside for_each lanes and subgraph runs; run-start/run-end/run-error remain intentionally un-forwarded so a workflow is not reported as starting once per item. The forwarding logic is now a single implementation, RunEvent::forParent(), shared by both executors — previously each executor carried its own copy, which is precisely how both came to be identically wrong. Worth flagging as a process gap: the durable-path tests were comprehensive and the human-facing-event path had no assertions at all. If we adopt, we should add coverage on the events our product actually renders.