Post-mortem n8n

Le 15 août 2026, après la reconstruction du compte propriétaire d'une instance n8n auto-hébergée, la connexion fonctionnait puis renvoyait aussitôt à l'écran de connexion. Les journaux du serveur ne montraient aucune erreur d'authentification. L'API et les 24 workflows ont continué à tourner, sans perte de données, mais l'éditeur était inaccessible.

L'authentification n'a jamais échoué. n8n trouve le projet personnel d'un utilisateur grâce à une colonne, et cette colonne pointait encore vers l'utilisateur supprimé. La console du navigateur montrait une erreur 404 sur l'adresse du projet personnel, une erreur que le serveur n'a jamais enregistrée.

Rien n'a été modifié au hasard. Des requêtes en lecture seule sur la base, les journaux confrontés aux heures exactes des connexions et des requêtes curl changées une variable à la fois ont d'abord confirmé la cause. Ensuite, un script a parcouru toutes les tables à la recherche de l'identifiant supprimé et a trouvé 726 références obsolètes, là où la réparation à la main en avait trouvé une.

Les corriger a aussi rétabli les clés d'API d'une intégration externe et de plusieurs workflows internes, qui échouaient en silence depuis des heures. Entre le blocage et la correction, il s'est écoulé environ 1 h 20.

Supprimer toute la ligne de l'utilisateur, au début, est ce qui a causé les dégâts ; effacer trois champs de double authentification aurait suffi. Depuis, je corrige les données et j'évite de les supprimer. Un message d'erreur de la deuxième réinitialisation décrivait la cause en clair, alors je lis désormais les erreurs comme des données. Et quand le serveur semble sain, je regarde vite le navigateur.