Définir précisément ce que représente l’index
Un indexeur transforme une activité blockchain sélectionnée en données consultables par l’application. Commencez par les questions attendues : transferts d’une adresse, positions d’un compte ou historique d’un contrat. Distinguez ce modèle de lecture des décisions métier, comme payer une facture ou accorder un accès. Notez les événements qui alimentent chaque vue et les confirmations nécessaires aux actions suivantes. Cette séparation permet de reconstruire un affichage sans répéter toutes les opérations commerciales déclenchées autrefois. Elle aide aussi le support à expliquer une correction sans la confondre avec une nouvelle action.
Utiliser le flux direct comme accélérateur
Les abonnements Geth fournissent des événements actuels et disparaissent lorsque leur connexion ferme ; ils ne remplacent pas la reprise historique. Associez les mises à jour directes à une lecture bornée qui repart d’une progression enregistrée. Définissez la rencontre des deux parcours sans doublons. La progression doit correspondre aux données effectivement validées, pas simplement à une réponse reçue. Demandez une coupure de connexion pendant la démonstration, suivie d’activité de test et d’une reconnexion. La période manquante doit être récupérée par un processus observable, sans réparation manuelle improvisée.
Conserver une identité suffisante pour chaque donnée
Une référence de transaction ne désigne pas nécessairement un seul événement applicatif. Prévoyez le réseau, le contrat, le bloc, la transaction et la position de l’événement adaptés à la chaîne. Séparez au besoin l’observation initiale de son interprétation actuelle afin d’expliquer les corrections. Définissez la détection des doublons et le suivi des versions du décodeur. Une question de réception est particulièrement utile : un opérateur peut-il partir d’une ligne du tableau de bord pour retrouver la preuve blockchain exacte et la version de traitement qui l’ont produite ?
Prévoir un traitement explicite des réorganisations
Geth peut signaler des journaux retirés lorsque leurs blocs sont remplacés par une réorganisation. Il faut donc traiter les observations qui ne font plus partie de l’historique canonique. Envisagez leur marquage, le recalcul des vues dépendantes et la relecture de la plage remplacée. Placez les effets métier irréversibles derrière une règle de confirmation distincte des affichages provisoires. Pendant la conception, simulez quelques blocs remplacés sur papier. Indiquez les changements en base, l’affichage client et l’alerte qui expliquera la correction à l’opérateur sans la présenter comme un nouveau transfert.
Rendre le retard et l’incertitude observables
Surveillez la progression par rapport à une tête de chaîne identifiée, les erreurs du prestataire, les plages non résolues et l’ancienneté de la dernière mise à jour réussie. Un processus actif peut néanmoins accumuler du retard. Prévoyez une date ou un statut temporaire lorsque l’historique client est incomplet. Les opérateurs doivent disposer de commandes de reprise bornées, avec une plage et un motif explicites. Évitez une relecture générale susceptible de répéter des actions métier sans aperçu de ses conséquences. Conservez également l’identité de la personne qui l’a déclenchée.
Tester les reprises avant de mesurer le débit
Avec des scénarios contrôlés, testez les événements répétés, une plage absente, un bloc modifié, une limite du prestataire et un arrêt entre l’enregistrement et l’avancement du curseur. Vérifiez qu’une reprise produit la même vue attendue qu’un traitement continu. Mesurez ensuite le débit avec les vrais types de contrats et de requêtes prévus. Exigez une procédure de migration et de reconstruction lors de la livraison. La meilleure preuve n’est pas une animation rapide une seule fois, mais une récupération documentée qui restaure des données cohérentes après une interruption réaliste.