<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Workflow-Engines on Kuldeep Pisda</title><link>https://kdpisda.in/tag/workflow-engines/</link><description>Recent content in Workflow-Engines on Kuldeep Pisda</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 21 Oct 2026 09:00:00 +0530</lastBuildDate><atom:link href="https://kdpisda.in/tag/workflow-engines/index.xml" rel="self" type="application/rss+xml"/><item><title>Jepsen on Orkes Conductor: The Sweeper That Only Reads the Queue Cannot Recover What the Queue Never Saw</title><link>https://kdpisda.in/jepsen-orkes-conductor-split-writes-sweeper-blind-spot/</link><pubDate>Wed, 21 Oct 2026 09:00:00 +0530</pubDate><guid>https://kdpisda.in/jepsen-orkes-conductor-split-writes-sweeper-blind-spot/</guid><description>&lt;p&gt;Conductor stores each workflow execution in Postgres and schedules its next step by pushing a message onto a decider queue in Redis. Jepsen&amp;rsquo;s &lt;a href="https://jepsen.io/analyses/orkes-conductor-5.3.2"&gt;report on Orkes Conductor&lt;/a&gt;, published on 2026-10-20, found that three of its serious safety bugs share one shape: the row and the message are two separate writes, and the process that repairs stuck work only reads one of them. Orkes funded the research, and Jepsen tested versions 5.3.2 through 5.5.0-rc2.&lt;/p&gt;</description></item></channel></rss>