We Asked Jepsen to Break Orkes Conductor

Orkes commissioned Jepsen researcher Kyle Kingsbury to test Orkes Conductor’s behavior under infrastructure failures such as process crashes, database and Redis outages, and network partitions, using recorded operation histories to evaluate whether system outcomes remained valid. The testing identified unexpectedly frequent concurrent task execution, workflow delays, several minor startWorkflow issues, and serious failures that could abandon, erase, or incorrectly complete workflows. Orkes confirmed the findings and addressed most of them: a race condition causing excess at-least-once task deliveries was fixed in v5.5.6, while dual-write failures during workflow startup were resolved in v5.5.0 through a transactional outbox that atomically records executions and queue entries and recovers interrupted starts. Seven of nine reported issues are closed, while a null workflow ID returned during Redis failures remains under investigation despite an SDK safeguard, and a potentially misleading “Failed to connect” error message remains open after retry behavior was corrected. Orkes concludes that Conductor continued operating through fault injection but acknowledges that ongoing failure-oriented design and testing are necessary for reliability.

No tracked trend matches for this post yet.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.