Un service qui refuse de démarrer sur un fichier de settings malformé. Lire la vraie stack trace plutôt que deviner, isoler le JSON fautif, le régénérer.
Un service crashe au démarrage et ne remonte pas. Le réflexe est de tester des hypothèses au hasard : permissions, port, dépendance manquante. C’est le moyen le plus lent. La cause est presque toujours déjà écrite dans les logs.
Lire la stack trace, pas la deviner
On ouvre le log de démarrage et on lit la trace complète, pas seulement la dernière ligne. Le type d’exception et le fichier mis en cause y figurent. Un crash sur un parse JSON pointe le fichier et souvent la position du caractère fautif.
Deviner fait tester dix pistes sans rapport avec le problème. La trace donne la réponse en une lecture : tel parseur a échoué sur tel fichier, à tel offset.
Isoler le fichier, puis le régénérer
Une fois le fichier identifié, on le valide hors du service avec un parseur strict. L’erreur signale l’endroit exact : virgule en trop, accolade non fermée, écriture tronquée à mi-chemin par un arrêt brutal.
Si le fichier est généré par l’application, le plus propre est de le supprimer ou le renommer et de laisser le service le régénérer depuis ses valeurs par défaut. On évite de réparer à la main un fichier que le code sait reconstruire.
Le principe : la trace est la source de vérité. On lit d’abord, on isole le fichier fautif, on le régénère plutôt que de le rafistoler.