Orkes Conductor 5.5.6 After Jepsen: What Operators Should Check
Jepsen published its analysis of Orkes Conductor on 20 October 2026 and recommended upgrading to 5.5.6 because it addresses the three serious safety issues identified in testing. Orkes published a companion response and changelog updates around the same time. For operators, the useful question is not whether every deployment is affected. It is which version you run, which behaviors are already fixed, and which workflows still require careful operational handling.
This draft focuses on the operator side: version inventory, worker idempotency, ambiguous workflow starts, and recovery checks. It also keeps a narrow distinction between the issues Jepsen found in versions 5.3.2, 5.4.0, and 5.5.0 release candidates, the fixes shipped in 5.5.0 and 5.5.6, and the remaining design realities of at-least-once delivery and possible concurrent execution.
What Jepsen tested, and what it reported
Jepsen says it tested Orkes Conductor 5.3.2, 5.4.0, and 5.5.0-rc1/-rc2 in a ten-machine setup with Postgres, Redis or Redis Cluster, multiple Conductor servers and workers, and injected process failures and network partitions. In that test environment, it found three serious safety issues that Jepsen says are addressed by upgrading to 5.5.6.
Orkes’s companion response says seven of nine issues are closed across 5.5.0 and 5.5.6. That matters for operators because not every observed failure mode has the same root cause or remediation path. Some fixes landed earlier in the release line, including the transactional-outbox fix for the dual-write path in 5.5.0.
Jepsen also notes that an extra duplicate-delivery behavior caused by a sweeper time-of-check/time-of-use issue was fixed in 5.5.6. Even so, at-least-once task delivery still means workers must be idempotent. That is not a bug report so much as an operating requirement.
Compact version and action table
- 5.3.2 / 5.4.0 / 5.5.0-rc1 / 5.5.0-rc2: treat as pre-fix or in-scope test versions; review urgently if any are still running in production or staging.
- 5.5.0: includes the transactional-outbox fix for the dual-write path, but do not assume this alone resolves all operator concerns.
- 5.5.6: Jepsen recommends upgrading here because it addresses the three serious safety issues identified in the analysis.
- Any version: keep worker code idempotent around external side effects, because at-least-once delivery remains the design model.
- Any version: review ambiguous workflow-start outcomes before retrying; a failed start call may still have created the workflow.
Two open or partly mitigated startWorkflow cases still need operator attention
Orkes says two issues remain open or partly mitigated. One is a null workflow ID case. Jepsen says Java client 6.0.2 contains a mitigation for null workflow IDs, but that is not the same as saying the underlying root cause is fully fixed.
The other is the meaning of a failed connection during startWorkflow. Jepsen’s warning here is practical: a failed start call can be indeterminate. The workflow may have been created. In that situation, do not assume retrying the call is harmless. Reconcile first, using a caller-supplied business or idempotency key, or another application-owned correlation record, before deciding whether to retry.
That reconciliation step is especially important for systems that react to payment, provisioning, account state, or other side effects. The point is to make the start path observable from the application side, not to infer a stronger API guarantee than the cited sources provide.
Five-step operator checklist
- Inventory server and client versions across environments. Confirm whether any Conductor servers, workers, or Java clients are still on versions tested by Jepsen.
- Confirm worker idempotency around external side effects. Retries and concurrent execution can happen, so task handlers should tolerate duplicate delivery.
- Review every ambiguous start outcome. If a startWorkflow call fails in a way that could be indeterminate, reconcile against your own business key or correlation record before retrying.
- Query for stuck or abandoned executions and compare them with the system of record. Look for cases where the workflow exists but the caller never recorded a success, or vice versa.
- Test failure and recovery behavior in staging. Recreate process failures and network partitions in a controlled environment so you know what your runbook says when an operator sees a partial failure.
Why upgrading is necessary but not sufficient
Upgrading to 5.5.6 is the right first move, but it is not the whole operation. Version drift between server and client components can leave teams with mixed assumptions about behavior. Worker code can still produce duplicate side effects if it is not written to be safe under retries. And ambiguous workflow starts can still create uncertainty even when the platform is improved.
That is why the operator checklist should include both platform tasks and application tasks. Platform teams can patch versions and inspect execution state. Application owners must decide how to detect duplicate starts, how to reconcile them, and how to make side effects safe when a task runs more than once.
Sources and follow-up reading
- Jepsen analysis of Orkes Conductor 5.3.2: https://jepsen.io/analyses/orkes-conductor-5.3.2
- Orkes companion response: https://orkes.io/blog/orkes-conductor-jepsen-testing
- Orkes durable execution and idempotency documentation: https://orkes.io/content/quickstart/durable-execution
- Orkes changelog: https://www.orkes.io/changelog
Check your operating assumptions
