The workflow engine said OK after a failed step
Why an RPC acknowledgement is not a workflow result, and which record to trust.
Plori Tech1 view
In the first end-to-end test of our embedded workflow engine, the host submitted a flow, the engine answered OK and the child process exited normally. The only step had failed, as the test intended.
The short answer
- An OK acknowledgement is not a workflow verdict. It shows the engine handled the command. The run-level result arrives in a separate run record.
- Define success from one durable terminal record that holds the run-level outcome. Billing, notifications, retries and the execution page should all read it.
- A missing record is never success. If the engine acknowledges the command but no terminal record exists, classify the run as indeterminate or a platform failure.
Three layers of "success"
| Layer | Question it answers | What success does not prove |
|---|---|---|
| Admission | Did the host accept the execution request? | That the engine started or any step ran |
| Transport or RPC | Did the engine handle the command without a protocol-level error? | That the workflow's steps succeeded |
| Workflow outcome | Did the run reach a defined terminal state? | Nothing above it; this is the user-visible result |
When it applies
- Test the real engine boundary: submit a workflow with one deterministic, side-effect-free step that must fail, then assert the run is failed, the failing step is identified and an error is present. Mocking the engine only proves the host handles the answer you expected.
- Repeat the test on every engine upgrade. We pin the embedded engine version because this contract is behavioral. In the Activepieces 0.86.3 path we embed, the engine writes its final run record before it acknowledges the command, and our host treats that order as a protocol obligation.
- Limits: the finding comes from a pinned Activepieces 0.86.3 engine behind our own host, not the stock Activepieces server. The messages and persistence path are version-specific.
The full post has the failure taxonomy, the three-case upgrade test and how Plori workflows expose execution state.