`laravel-workflow` is abandoned upstream, with no successor chosen

Reopened 2026-08-31, because the case made for it was wrong. The original entry justified this question with "7 Sentry issues, ~28,500 events, climbing since 2026-05-11, all one systemic root cause". They are not one root cause. 28,403 of those 28,518 events were TELECOM-COMPARATOR-NT, which is a data problem in our own repo and has nothing to do with this package's health — it is now OS-003. What is genuinely attributable to how we call this library is ~115 events, flat. The abandonment is real and still worth settling; the volume argument for urgency was not.

The fact. composer.lock marks laravel-workflow/laravel-workflow (pinned ^1.0, resolved 1.0.76) as abandoned, with a replacement named by the package itself: durable-workflow/workflow. This is the lockfile's own flag, not a judgement — nobody upstream is fixing anything in it again.

What is actually attributable to the library (Sentry project telecom-comparator):

One family: a call-convention mismatch between our code and the library, sitting in selectra/comparator-core. That clone was added to the repo registry on 2026-08-27, so a triage run can now read makeChild()'s actual contract and may fix the proximate bug in v3 without you.

What is being asked. Whether to stay on an abandoned workflow engine at all. Roughly:

1. Accept and patch around it — cheapest now; every future workflow bug is ours to work around in comparator-core, forever, with no upstream fixes.
2. Migrate to durable-workflow/workflow — the successor the package points at. Real project work, and somebody has to size it.
3. Fork laravel-workflow — we control it, we maintain it. Worth it only if the surface we use is small.

Why the earlier answer needed re-confirming. On 2026-08-28 the answer was "OS-001 yes, replace with new version" — read as option 2, migrate. It was given against a claim of 28.5k errors/week that this package was not causing, and a migration would not have fixed those errors: the orphaned rows in OS-003 would have migrated along with us. Option 2 may well still be right — but it should be chosen on maintenance risk and on how much of the library the comparators actually use, not on an error count that a one-line data fix ends.

Answer (2026-09-01, users/108934946863892655718) : "OS-001 yes, let update to durable-workflow/workflow" — read as: option 2, migrate to durable-workflow/workflow, confirmed after the entry was reopened and re-scoped to the ~115-event call-convention issue.