- Is solution-forest/workflow-engine-core compatible with Laravel?
- Yes, but indirectly. The package is framework-agnostic and has no Laravel dependency, so it installs cleanly into a Laravel app, and its event system and plugin/action architecture are the right seams for wiring Laravel Event, Queue, and Mail. What you do not get out of the box is a QueueExecutor, a database storage adapter, or a production mail action — those you build against your Laravel app. Core orchestration, conditions, and state tracking work fine inside Laravel, especially with the bundled InMemoryStorage for local, dev, and test environments.
- How do I install workflow-engine-core with Composer?
- Require it with composer require solution-forest/workflow-engine-core on PHP 8.3 or newer. The package now ships Storage\InMemoryStorage, so a workflow can actually execute immediately after install rather than requiring test fixtures. Because v2.0.0 followed v1.0.0 within hours, pin an exact tag in composer.json instead of relying on a caret constraint. Verify that ext-curl is present in your base images, since HttpAction reports a missing curl extension as a step failure rather than a fatal error.
- Does workflow-engine-core support retries and timeouts for workflow steps?
- No. As of v2.0.0, step-level retries and timeouts are explicitly out of scope, and the documentation that previously claimed them has been removed. Treat retry and timeout handling as work your application owns — typically through queue job retries, middleware, or a wrapper around step execution. The README still lists retry logic and timeouts as features, so check the release notes rather than the feature list before designing around them.
- What PHP version does workflow-engine-core require?
- PHP 8.3 or higher is required; the library leans on modern typing features for type safety and performance. There are no framework dependencies, so it runs in plain PHP, Laravel, Symfony, or any other project. Composer is the only install-time requirement. You should also confirm ext-curl in your runtime images if you plan to use HttpAction.
- How do I persist workflow state to a database instead of using InMemoryStorage?
- InMemoryStorage is bundled for local, dev, and test use only — there is no database adapter shipped with the package. You implement your own storage adapter against the package's storage contract, backed by Eloquent or the query builder, and register it when building the engine. Read the current interfaces before starting, since the API moved twice in one day and a prior release removed internal helpers such as data_get() and data_set() without documenting it. Plan a thin adapter first and add indexing on workflow instance id and status before production volumes.
- Can a failed workflow be resumed or retried after an error?
- Yes in v2.0.0: FAILED is no longer terminal, FAILED to RUNNING is a legal transition, and resume() retries the failed step. That makes human-in-the-loop and remediation flows practical, whereas earlier versions left resume() unusable after a failure. Workflows whose prerequisites are unmet now park in WAITING, which is distinguishable from an actively executing workflow. If any handler or dashboard of yours assumes FAILED is a dead end, update it during your upgrade audit.
- What breaking changes are in workflow-engine-core v2.0.0 and should I upgrade?
- v2.0.0 is a breaking major and arrived hours after v1.0.0, so semver is being applied correctly but the cadence signals a pre-stabilisation API. The breaking surface includes EmailAction becoming FakeEmailAction, WorkflowBuilder::email() becoming fakeEmail(), ConditionAction dropping on_true/on_false, the condition grammar moving from =/is to ===/==/!=, and FAILED no longer being terminal. Upgrade only after grepping for those symbols and after identifying any workflow whose passing result depended on the old silent string-comparison behaviour, since those conditions now throw at parse time. Pin exact tags either way.
- How do I write conditions in workflow-engine-core?
- The condition engine now parses real expressions: boolean operators, parentheses, negated groups, and comparisons using ===, ==, and != instead of the old = and is syntax. Malformed expressions are rejected at parse time rather than silently evaluating. That is a meaningful upgrade, because the previous evaluator string-compared values and returned true for a 500-dollar order against 'order.total > 1000 && order.vip === true'. Migrate stored condition strings before deploying, and expect parse-time failures for anything that only passed by accident.
- Is workflow-engine-core ready for production use?
- Not yet. The package is explicitly marked as under active development and not ready for production, and the release history (two majors in one day) supports that caution. It is a reasonable fit for a pilot: synchronous, non-critical flows on InMemoryStorage with pinned tags and your own acceptance assertions. Because several releases fixed silent-success defects where the engine reported completion for dropped or misrouted branches, treat engine-reported status as an internal signal and verify business outcomes yourself.
- How do I run workflows asynchronously or trigger Laravel events and mail from a workflow?
- Use the event system plus the plugin and custom action architecture — those are unchanged in v2.0.0 and are the intended extension points. From a custom action or an event listener you can dispatch a Laravel queued job, fire an event, or send mail through your app's mailer. The package itself provides neither a QueueExecutor nor a real email action (EmailAction is now a fake for testing), so asynchronous execution is code you own. Start with SimpleWorkflow for synchronous flows and add the queued path once your storage adapter is stable.