Camunda 7 – Les retries des External Tasks ne fonctionnent pas

Camunda 7 – Les retries des External Tasks ne fonctionnent pas : causes et solutions

Les External Tasks sont très utilisées dans Camunda 7 pour découpler la logique métier du moteur BPM.
Cependant, un problème très fréquent en production est le suivant :

❌ Les retries des External Tasks ne se déclenchent pas correctement.

Dans cet article, nous expliquons pourquoi les retries échouent, les causes réelles, et surtout comment corriger le problème de manière sûre en production.

---

1️⃣ Fonctionnement des retries des External Tasks dans Camunda 7

Dans Camunda 7, les retries sont contrôlés par :

• Le nombre de retries

• Le lockDuration

• Le lockExpirationTime

• La logique d’erreur implémentée dans le worker

👉 Un retry n’est déclenché que si le worker appelle explicitement handleFailure().

---

2️⃣ Causes les plus fréquentes lorsque les retries ne fonctionnent pas

❌ 1. handleFailure() n’est pas appelé correctement

Implémentation incorrecte (très courante) :

try {
   // logique métier
} catch (Exception e) {
   throw e; // ❌ Ne déclenche pas de retry
}

Implémentation correcte :

externalTaskService.handleFailure(
    externalTask,
    "Erreur de traitement",
    e.getMessage(),
    retries,
    retryTimeout
);

👉 Sans appel à handleFailure(), Camunda considère la tâche comme réussie.

---

❌ 2. Le nombre de retries est déjà à zéro

Si retries = 0, Camunda n’effectuera plus aucun retry.

Vérifier dans :

• Cockpit → External Tasks → colonne Retries

Correction :

externalTaskService.setRetries(externalTask, 3);

Ou réinitialiser manuellement depuis Cockpit.

---

❌ 3. lockDuration trop court

Si la durée de verrouillage est trop faible :

• La tâche est libérée avant la fin du traitement

• Un autre worker peut la récupérer

• Le comportement des retries devient imprévisible

Correction :

client.subscribe("topic")
  .lockDuration(10000) // 10 secondes ou plus
  .handler(...)

👉 Règle simple :
lockDuration > temps maximal d’exécution

---

❌ 4. Le worker s’arrête avant de signaler l’échec

Si le worker :

• Crashe

• Est stoppé

• Perd la connexion réseau

Alors :

• handleFailure() n’est jamais appelé

• Aucun retry n’est planifié

👉 Comportement normal, pas un bug Camunda.

La tâche redeviendra disponible uniquement après l’expiration du lock.

---

3️⃣ Mauvaise compréhension du retryTimeout

Beaucoup pensent que les retries sont immédiats.

Mais :

retryTimeout = 60000; // 1 minute

👉 Camunda attend 1 minute avant de rendre la tâche à nouveau disponible.

Un timeout élevé donne l’impression que les retries ne fonctionnent pas.

---

4️⃣ Erreur BPMN vs retry technique (erreur fréquente)

❌ Utiliser une erreur BPMN pour une erreur technique :

throw new BpmnError("ERROR_CODE");

Cela :

• Interrompt définitivement le retry

• Fait avancer le processus

✅ Utiliser les retries pour :

• Problèmes réseau

• Timeouts base de données

• Erreurs temporaires

👉 Les BPMN Errors sont réservées aux erreurs métier.

---

5️⃣ Problèmes de souscription au topic External Task

Vérifier :

• Le nom du topic (doit correspondre exactement au BPMN)

• Que le worker est bien démarré

• Que le polling est actif

Activer les logs :

org.camunda.bpm.client=DEBUG

---

6️⃣ Checklist de diagnostic en production

✅ Vérifier le nombre de retries dans Cockpit
✅ Analyser les logs du worker
✅ Confirmer l’appel à handleFailure()
✅ Vérifier lockDuration
✅ Vérifier retryTimeout
✅ Vérifier que le worker est actif

---

7️⃣ Stratégie de retry recommandée (production-safe)

int retriesLeft = externalTask.getRetries() != null
        ? externalTask.getRetries() - 1
        : 3;

externalTaskService.handleFailure(
    externalTask,
    "Erreur temporaire",
    errorMessage,
    retriesLeft,
    30000
);

👉 Avantages :

• Retries contrôlés

• Pas de boucle infinie

• Comportement stable en production

---

🔑 Conclusion

Les retries des External Tasks ne tombent jamais en panne par hasard.

Dans 90 % des cas, le problème vient de :

• L’absence de handleFailure()

• Un compteur de retries à zéro

• Un lockDuration mal configuré

• Une mauvaise gestion des exceptions

---

💼 Accompagnement professionnel

Si vous rencontrez :

• Des problèmes de retries en production

• Des erreurs External Task difficiles à diagnostiquer

• Des besoins d’optimisation Camunda

Je propose du support production, du conseil et de la formation Camunda.

📧 Contact : ishikhanirankari@gmail.com | info@realtechnologiesindia.com

🌐 Website : IT Trainings | Digital lectern | Digital rostrum | Digital metal podium