Jepsen Temukan 3 Bug Serius di Orkes Conductor, Patch di 5.5.6

Jepsen menguji Orkes Conductor versi 5.3.2 sampai 5.5.0-rc2 dan menemukan tiga masalah serius: eksekusi workflow bisa ditinggalkan permanen, dilupakan, atau ditandai selesai padahal task-nya tidak pernah dijalankan. Laporan yang terbit 20 Oktober 2026 itu juga mencatat eksekusi task konkuren yang jauh lebih sering dari perkiraan, satu isu yang bisa menunda eksekusi secara signifikan, dan empat masalah kecil soal error startWorkflow serta ID null. Orkes sudah merilis 5.5.6 untuk menambal seluruh isu keselamatan yang serius.

TL;DR

• Jepsen menguji Orkes Conductor 5.3.2 hingga 5.5.0-rc2 dan menemukan tiga masalah yang bisa membuat workflow hilang atau salah ditandai selesai.
• Versi 5.5.6 sudah menambal seluruh isu keselamatan serius, mengurangi eksekusi task konkuren, dan memperbaiki dua error startWorkflow.
• Dua error startWorkflow lain masih dalam penyelidikan, jadi belum ada patch untuk keduanya.
• Penundaan eksekusi yang ditemukan dianggap konsisten dengan parameter desain Conductor dan tidak perlu diperbaiki.
• Penelitian ini didanai Orkes sendiri, dan Jepsen mencantumkan hal itu terbuka di laporannya.

Apa Itu Orkes Conductor?

Orkes Conductor adalah platform orkestrasi workflow yang menjalankan task-task buatan pengguna dan mengalirkan data antar task tersebut. Conductor awalnya dibangun Netflix dan dirilis sebagai open source pada 2016, lalu versi open source-nya, Conductor OSS, kini dikelola Conductor OSS Foundation yang dipimpin Orkes. Orkes juga menjual versi hosted dengan fitur tambahan, dan versi itulah yang diuji Jepsen dalam laporan ini.

Secara arsitektur, Conductor terdiri dari server stateless yang mengelola workflow dan menjadwalkan eksekusi, basis data untuk menyimpan definisi serta status, queue untuk mendistribusikan pekerjaan, dan dua kumpulan worker: worker standar untuk task bawaan serta worker kustom yang ditulis pengguna lewat SDK. Worker tidak dipanggil langsung; mereka melakukan polling ke server, mengambil task, menjalankannya, lalu mengirim hasil kembali.

Model polling itu punya konsekuensi yang penting untuk memahami temuan Jepsen. Karena task dikirim lewat queue dan dijalankan oleh worker yang jumlahnya bisa berapa saja, jaminan yang diberikan adalah at-least-once: setiap pesan akan dikirim satu kali atau lebih. Artinya duplikasi eksekusi bukan pelanggaran kontrak, tapi harus tetap dibatasi supaya tidak jadi masalah biaya dan konsistensi. Repositori Conductor OSS ada di github.com/conductor-oss/conductor.

Apa Saja Temuan Jepsen?

Jepsen membagi temuannya berdasarkan tingkat keparahan. Yang paling penting bukan jumlah temuan, tapi sifatnya: sebagian masalah membuat workflow berhenti tanpa status yang benar, dan itu jenis kegagalan yang paling sulit dideteksi dari dashboard.

Tingkat	Temuan	Dampak
Serius	Workflow ditinggalkan atau dilupakan secara permanen	Eksekusi tidak pernah mencapai status terminal
Serius	Workflow ditandai selesai padahal task belum dijalankan	Klaim sukses palsu pada alur bisnis
Serius	Kelompok masalah yang membuat eksekusi hilang dari sistem	Pemulihan manual tanpa jejak yang jelas
Sedang	Eksekusi task konkuren jauh lebih sering dari perkiraan	Duplikasi kerja dan efek samping ganda
Ringan	Empat isu error startWorkflow dan ID null	Kegagalan saat memulai workflow
Desain	Penundaan eksekusi yang signifikan	Dianggap sesuai parameter, tidak perlu diperbaiki

Laporan lengkap, termasuk skenario pengujian dan bukti kegagalan, bisa dibaca di analisis Jepsen untuk Orkes Conductor 5.3.2. Jepsen juga mencatat bahwa Orkes menerbitkan tulisan pendamping soal temuan ini.

Versi Mana yang Harus Dipakai?

Kalau lo menjalankan Conductor untuk workflow yang punya efek samping nyata, versi 5.5.6 adalah batas minimum yang masuk akal. Versi itu menambal seluruh masalah keselamatan yang serius, mengurangi frekuensi eksekusi task konkuren, dan memperbaiki dua dari empat error startWorkflow. Dua error sisanya masih diselidiki, jadi belum ada versi yang menutup semuanya.

Untuk tim yang masih di 5.3.2, laporan ini memberi alasan kuat untuk naik versi. Perlu dicatat, Jepsen menguji rentang 5.3.2 sampai 5.5.0-rc2, sehingga versi di antaranya belum tentu punya profil kegagalan yang sama persis. Yang bisa dipegang: patch untuk masalah serius baru tersedia di 5.5.6.

Satu hal yang juga perlu diperhatikan adalah perubahan di 5.4.0. Versi itu memperkenalkan opsi memakai sistem penyimpanan lossy untuk semua queue kecuali queue decider utama. Secara desain itu wajar untuk mengejar throughput, tapi kalau tim mengaktifkannya tanpa memahami konsekuensinya, jaminan pengiriman pesan bisa melunak. Sebelum mengaktifkan opsi semacam itu, pastikan jenis task yang berjalan di queue tersebut memang tahan terhadap kehilangan pesan.

Kenapa Eksekusi Task Konkuren Berlebih Itu Masalah?

Karena banyak task tidak idempoten. Kalau satu task mengirim email, memotong saldo, atau memanggil API pihak ketiga yang menagih per panggilan, eksekusi ganda langsung berubah jadi kerugian nyata. Pada sistem dengan jaminan at-least-once, duplikasi memang mungkin, tapi frekuensinya harus bisa diprediksi dan dibatasi oleh mekanisme idempotency di sisi worker.

Jepsen menyebut frekuensi eksekusi konkuren di Conductor jauh lebih tinggi dari perkiraan. Bagi tim yang menganggap duplikasi sebagai kejadian langka, angka itu mengubah asumsi dasar: kode worker harus dirancang untuk menangani eksekusi paralel sejak awal, bukan sebagai pengecualian yang ditangani manual saat insiden.

Pola yang biasanya dipakai: kunci idempotency berbasis workflow ID dan task execution ID, penulisan status yang bersifat compare-and-set, dan operasi eksternal yang menerima kunci idempotency dari penyedia layanan. Tanpa salah satu dari tiga lapisan itu, duplikasi akan tetap terasa seperti bug acak meskipun perilakunya sudah terdokumentasi.

Apa Arti At-Least-Once dalam Praktik?

Artinya Conductor menjamin pesan task akan sampai ke worker minimal satu kali, dan workflow yang sudah mulai akan berjalan sampai selesai selama semua task-nya selesai. Jaminan itu tidak berarti workflow selalu berakhir sukses: task bisa kehabisan retry, gagal dengan error non-retryable, atau dibatalkan, dan status akhirnya tetap salah satu dari COMPLETED, FAILED, TIMED_OUT, atau TERMINATED.

Masalah yang ditemukan Jepsen justru menyerang bagian "selama semua task selesai" itu. Kalau eksekusi ditinggalkan permanen, workflow tidak pernah mencapai status terminal, dan itu melanggar janji bahwa setiap eksekusi akan konvergen ke salah satu status akhir. Bagi sistem yang memakai status workflow sebagai sumber kebenaran untuk proses bisnis, kondisi itu berarti ada pekerjaan yang menggantung tanpa penanda.

Karena itu pemantauan yang hanya melihat error rate tidak cukup. Yang perlu dipantau adalah eksekusi yang berumur jauh di atas normal tanpa status terminal. Metrik seperti itu biasanya sepi, jadi butuh ambang khusus dan pemeriksaan berkala, bukan sekadar alert berbasis lonjakan.

Bagaimana Menyikapi Laporan yang Didanai Vendor?

Jepsen mencantumkan secara terbuka bahwa penelitian ini didanai Orkes dan dijalankan sesuai kebijakan etika mereka. Keterbukaan itu penting, tapi bukan jaminan netralitas. Cara membacanya: perlakukan temuan sebagai hipotesis yang bisa diuji, dan prioritaskan temuan yang disertai bukti konkret seperti log, rekaman kegagalan, atau skenario yang bisa direproduksi.

Dalam kasus ini, pihak vendor justru menerima temuan dan merilis patch, yang secara praktis memperkuat kredibilitas laporan. Kalau vendor menolak seluruh temuan, laporan yang sama akan lebih sulit dipakai sebagai dasar keputusan. Yang tetap perlu dilakukan tim platform: verifikasi sendiri di versi yang dipakai, karena lingkungan produksi selalu punya konfigurasi berbeda dari lab.

Tulisan pendamping dari pihak vendor bisa dibaca di blog Orkes, dan berguna untuk melihat bagaimana mereka menjelaskan patch 5.5.6 dari sisi pengguna.

Yang juga layak diapresiasi adalah pemisahan antara bug dan konsekuensi desain. Jepsen menyebut penundaan eksekusi konsisten dengan parameter desain Conductor dan tidak perlu diperbaiki. Pemisahan seperti itu membantu tim memilih mana yang harus ditunggu patch-nya dan mana yang harus disesuaikan ekspektasinya.

Apa yang Perlu Dicek Tim Platform?

Pertama, versi. Kalau masih di bawah 5.5.6, jadwalkan upgrade dan uji ulang workflow yang paling kritis. Kedua, idempotency worker: audit task yang punya efek samping eksternal dan pastikan semuanya tahan eksekusi ganda. Ketiga, pemantauan eksekusi menggantung, karena itu gejala utama dari masalah yang paling serius di laporan ini.

Keempat, konfigurasi queue. Kalau opsi penyimpanan lossy diaktifkan, pastikan hanya untuk queue yang memang boleh kehilangan pesan. Kelima, dokumentasi status terminal: pastikan setiap workflow punya jalur penanganan untuk eksekusi yang berakhir TIMED_OUT atau TERMINATED, bukan hanya COMPLETED dan FAILED.

Terakhir, siapkan jalur eskalasi. Kalau setelah upgrade masih ada workflow yang menggantung tanpa status, itu bahan laporan yang berguna untuk vendor, dan sebaiknya dikirim dengan bukti lengkap: workflow ID, waktu mulai, status task terakhir, dan log worker terkait.

Bagaimana Memetakan Risiko Ini ke Alur Bisnis?

Cara paling cepat: daftar semua workflow, lalu tandai mana yang efek sampingnya tidak bisa dibatalkan. Pengiriman uang, penerbitan invoice, pengiriman email ke pelanggan, dan provisioning resource termasuk kategori yang mahal kalau terjadi ganda atau malah tidak pernah jalan. Workflow yang hanya membaca data dan menyusun laporan biasanya bisa menunggu patch tanpa risiko berarti.

Setelah daftar itu jadi, petakan tiap workflow ke status terminal yang diharapkan. Kalau sebuah workflow seharusnya selalu berakhir COMPLETED dan kegagalannya ditangani manual, maka risiko "ditinggalkan permanen" berarti ada pekerjaan yang diam-diam tidak pernah selesai. Sebaliknya, kalau ada job harian yang memeriksa eksekusi berumur lebih dari beberapa jam, risiko itu sudah termitigasi sebagian.

Langkah berikutnya adalah memilih dua atau tiga workflow paling kritis untuk diuji ulang setelah upgrade. Uji dengan skenario yang tidak normal: worker mati di tengah task, koneksi ke basis data terputus sebentar, dan queue penuh. Pengujian di jalur normal hanya membuktikan sistem bisa jalan, bukan bahwa sistem bisa pulih.

Hasil pengujian itu sebaiknya disimpan sebagai catatan yang bisa dibaca ulang, lengkap dengan versi yang diuji dan konfigurasi yang dipakai. Tanpa catatan seperti itu, pertanyaan "apakah kita sudah aman setelah upgrade" akan selalu dijawab dengan ingatan, dan ingatan bukan bukti.

FAQ

Apakah semua workflow terdampak bug ini?

Tidak semua. Masalah paling serius muncul pada skenario tertentu yang diuji Jepsen, terutama saat ada gangguan pada komponen penyimpanan atau queue. Tetap bijak menganggap setiap workflow dengan efek samping eksternal sebagai kandidat yang perlu pengujian ulang.

Apakah Conductor OSS juga terdampak?

Laporan ini fokus pada Orkes Conductor, versi hosted dengan fitur tambahan. Conductor OSS berbagi basis kode, jadi temuan di area yang sama layak diuji, tetapi klaim patch 5.5.6 berlaku untuk produk Orkes yang diuji.

Apakah penundaan eksekusi termasuk bug?

Bukan. Jepsen menyebut penundaan itu konsisten dengan parameter desain Conductor dan tidak perlu diperbaiki. Kalau tim butuh latensi lebih ketat, penyesuaiannya ada di konfigurasi dan arsitektur worker, bukan di patch vendor.

Kenapa eksekusi task bisa berjalan ganda?

Karena jaminan pengirimannya at-least-once. Pesan bisa terkirim lebih dari sekali saat terjadi retry atau pemulihan, dan worker yang tidak idempoten akan menjalankan efek sampingnya dua kali. Solusinya ada di desain worker, bukan hanya di sisi server.