Camunda Cockpit affiche un incident sans message d’erreur – Causes et solutions

Dans Camunda 7, les incidents Cockpit servent à identifier rapidement les échecs d’exécution.
Cependant, un problème fréquent en production est le suivant :

❌ Un incident apparaît dans Cockpit, mais aucun message d’erreur clair ni stack trace n’est visible.

Cet article explique pourquoi cela arrive, comment retrouver la véritable cause, et les solutions concrètes utilisées en environnement entreprise.

---

1️⃣ Qu’est-ce qu’un incident dans Camunda ?

Un incident est créé lorsque :

• l’exécution d’un job échoue,

• le nombre de retries atteint 0,

• le moteur ne peut plus continuer l’exécution du processus.

Les incidents concernent généralement :

• des Service Tasks,

• des External Tasks,

• des Timers,

• des continuations asynchrones.

---

2️⃣ Pourquoi Cockpit affiche un incident sans erreur

🔴 Cause 1 : L’erreur réelle s’est produite plus tôt

Camunda affiche souvent le dernier état connu, pas toujours l’exception initiale.

📌 L’erreur peut s’être produite :

• lors d’une étape async précédente,

• dans un delegate exécuté avant,

• pendant une tentative de retry antérieure.

✅ Solution :

• Consulter History → Incidents

• Analyser les logs moteur autour de l’horodatage de la première erreur

---

🔴 Cause 2 : L’exception est masquée dans le code personnalisé

Exemple courant :

try {
   // logique métier
} catch (Exception e) {
   log.error("Erreur détectée");
}

L’exception est absorbée, Camunda ne peut pas l’afficher.

✅ Solution : toujours relancer l’exception

catch (Exception e) {
   throw new RuntimeException(e);
}

---

🔴 Cause 3 : Incident lié au job, pas à l’élément BPMN

Les incidents sont associés aux jobs, pas directement aux tâches BPMN.

Cockpit peut donc afficher :

• un incident au niveau du processus,

• sans message d’erreur visible sur la tâche.

✅ Solution :

• Ouvrir Cockpit → Jobs

• Identifier le Job ID en échec

• Corréler avec les logs via l’heure d’exécution

---

🔴 Cause 4 : Logs insuffisants (DEBUG désactivé)

Les logs par défaut sont parfois trop limités.

✅ Solution : activer le DEBUG temporairement

org.camunda.bpm.engine.jobexecutor=DEBUG
org.camunda.bpm.engine.impl.persistence.entity=DEBUG

Cela permet de voir :

• l’acquisition des jobs,

• les erreurs d’exécution,

• la gestion des retries.

---

🔴 Cause 5 : Échec d’un External Task

Avec les External Tasks :

• le worker peut crasher,

• l’erreur métier n’est pas correctement remontée,

• le timeout est dépassé.

Cockpit montre un incident sans stack trace moteur.

✅ Solution :

• Vérifier les logs du worker

• S’assurer que handleFailure() est appelé avec les détails d’erreur

---

🔴 Cause 6 : Rollback transactionnel sans message clair

Des problèmes comme :

• deadlocks base de données,

• violations de contraintes,

• timeouts transactionnels,

peuvent générer un incident sans message explicite dans Cockpit.

✅ Solution :

• Examiner les logs DB

• Activer les logs SQL

• Vérifier les logs du serveur applicatif

---

🔴 Cause 7 : Niveau d’historique insuffisant

Si le niveau d’historique est none ou activity, Camunda ne stocke pas tous les détails.

✅ Solution : définir l’historique à full

<property name="history">full</property>

---

3️⃣ Méthode rapide pour trouver la vraie erreur

✔ Cockpit → Incidents
✔ Identifier le Process Instance ID
✔ Analyser les logs moteur par horodatage
✔ Vérifier ACT_RU_JOB et ACT_RU_INCIDENT
✔ Consulter les logs des workers externes (si utilisés)

---

4️⃣ Requêtes SQL utiles

SELECT * FROM ACT_RU_INCIDENT;

SELECT ID_, EXCEPTION_STACK_ID_
FROM ACT_RU_JOB
WHERE RETRIES_ = 0;

Le champ EXCEPTION_STACK_ID_ permet de retrouver la stack trace associée.

---

5️⃣ Bonnes pratiques en production

✅ Ne jamais masquer les exceptions
✅ Logger les stack traces complètes
✅ Activer DEBUG temporairement si nécessaire
✅ Surveiller incidents et retries
✅ Utiliser le niveau d’historique full

---

6️⃣ Besoin d’un accompagnement expert ?

Si :

• des incidents apparaissent sans explication,

• le débogage production prend trop de temps,

• les erreurs surviennent sous charge,

un accompagnement professionnel est recommandé.

---

💼 Support professionnel disponible

Si vous rencontrez des problèmes sur des projets réels en production liés aux incidents Camunda, aux échecs de jobs ou à l’absence de messages d’erreur, je propose des services de conseil payants, débogage en production, support projet et formations ciblées.

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

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