Contexte et architecture

Orkes Conductor est un orchestrateur de workflows dérivé de Netflix Conductor. La version 5.3.2 repose sur cinq composants majeurs : serveurs sans état, une base de données (Postgres, Cassandra ou Redis), une file d’attente (souvent Redis), ainsi que deux pools de workers (standard et personnalisés). Chaque serveur expose une API REST, persiste les définitions et l’état des exécutions, puis utilise la file d’attente pour dispatcher les tâches aux workers qui pollent le serveur, exécutent le code et renvoient le résultat.

Les garanties officielles indiquent une livraison au moins une fois des messages et une terminaison éventuelle de chaque workflow, même en présence de pannes réseau ou de redémarrages de nœuds.

Garantie annoncée vs comportement observé

Le test Jepsen a reproduit un déploiement typique : un nœud Postgres, un nœud Redis (ou un cluster Redis), plusieurs serveurs Conductor et des workers Java SDK (v5.0.1). Le scénario de charge crée un workflow simple contenant une tâche unique qui dort jusqu’à 30 s, génère une sortie aléatoire et journalise son exécution. Le harness invoque 

conductorClient.startWorkflow(workflowName, input)
puis interroge l’état via 
conductorClient.getWorkflow(workflowId)
.

Sous partitions réseau entre les serveurs Conductor et la base/queue, ainsi que sous arrêts forcés de processus, le système a présenté deux écarts majeurs :

  • Des messages ont disparu : certaines tâches n’ont jamais été re‑enregistrées dans la file d’attente, violant la promesse « at‑least‑once ». Le journal du harness montre des IDs de tâche attendus mais absents du serveur après récupération.
  • Des workflows sont restés bloqués indéfiniment, ne passant jamais à un état terminal (COMPLETED, FAILED, TIMED_OUT ou TERMINATED). La profondeur de la file d’attente « decider » ne s’est jamais remise à zéro, indiquant un état de limbo.

Ces anomalies surviennent même lorsque la base de données et la file d’attente sont configurées en mode persistant, ce qui contredit la documentation de la version 5.3.2.

Scénarios de panne et résultats du test

Le test a introduit trois types de fautes :

  1. Pause et kill de processus serveur ; les workers continuent de poller, mais les réponses de persistance sont perdues.
  2. Partitions réseau ciblant uniquement la connexion serveur‑Postgres ; les serveurs continuent de planifier des tâches sans pouvoir enregistrer l’avancement.
  3. Partitions réseau ciblant serveur‑Redis ; les messages en cours de dispatch sont jetés, entraînant des duplications ou des pertes.

Dans chaque cas, la récupération (re‑connexion, redémarrage) n’a pas rétabli la cohérence. Les workflows déjà démarrés ont affiché des états intermédiaires incohérents, et des exécutions de tâche ont été comptabilisées plusieurs fois avec des sorties différentes, contredisant l’affirmation d’Orkes selon laquelle « une fois le résultat visible, il ne change jamais ».

Implications et limites

Ces résultats suggèrent que la version 5.3.2 ne fournit pas les garanties de fiabilité attendues pour des environnements critiques. Les opérateurs doivent envisager des mécanismes de compensation : idempotence au niveau de la tâche, surveillance de la profondeur de la file d’attente et redéploiement de la file en mode persistant. Le rapport ne couvre pas les versions ultérieures (5.4.0, 5.5.0‑rc) qui introduisent un stockage « lossy » pour certaines files, ce qui pourrait aggraver les problèmes observés.

En l’état, les équipes DevOps qui déploient Orkes Conductor 5.3.2 dans des clouds publics doivent planifier des tests de résilience similaires et ne pas se fier uniquement aux garanties documentées.