Débogage rapide et facile des subgraph à l'aide de Forks

Comme pour de nombreux systèmes traitant de grandes quantités de données, les Indexeurs de The Graph (Graph Nodes) peuvent prendre un certain temps pour synchroniser votre subgraph avec la blockchain cible. L’écart entre les changements rapides dans le but de déboguer et les longs temps d’attente nécessaires à l’indexation est extrêmement contre-productif et nous en sommes bien conscients. C’est pourquoi nous introduisons Subgraph forking, développé par LimeChain⁠, et dans cet article je vous montrerai comment cette fonctionnalité peut être utilisée pour accélérer considérablement le débogage du subgraph !

D’accord, qu’est-ce que c’est ?

Le Subgraph forking est le processus de récupération paresseuse d’entités à partir du store d’un autre subgraph (généralement un store distant).

Dans le contexte du débogage, Subgraph forking vous permet de déboguer votre subgraph défaillant au bloc X sans avoir besoin d’attendre la synchronisation au bloc X.

Quoi ? Comment ?

Lorsque vous déployez un subgraph vers un Graph Node distant pour l’indexation et qu’il échoue au bloc X, la bonne nouvelle est que le Graph Node servira toujours les requêtes GraphQL à l’aide de son store, qui est synchronisé avec le bloc X. C’est formidable ! Cela signifie que nous pouvons tirer parti de ce store “à jour” pour corriger les bugs survenant lors de l’indexation du bloc X.

En bref, nous allons forker le subgraph défaillant à partir d’un Graph Node distant qui est garanti d’avoir le subgraph indexé jusqu’au bloc X afin de fournir au subgraph déployé localement et débogué au bloc X une vue à jour de l’état de l’indexation.

S’il vous plaît, montrez-moi du code !

Pour rester concentré sur le débogage des subgraphs, gardons les choses simples et exécutons le Subgraph d’exemple⁠ indexant le contrat intelligent Ethereum Gravity.

Voici les gestionnaires définis pour indexer Gravatars, sans aucun bug :

1export function handleNewGravatar(event: NewGravatar): void {2  let gravatar = new Gravatar(event.params.id.toHex().toString())3  gravatar.owner = event.params.owner4  gravatar.displayName = event.params.displayName5  gravatar.imageUrl = event.params.imageUrl6  gravatar.save()7}89export function handleUpdatedGravatar(event: UpdatedGravatar): void {10  let gravatar = Gravatar.load(event.params.id.toI32().toString())11  if (gravatar == null) {12    log.critical('Gravatar introuvable!', [])13    return14  }15  gravatar.owner = event.params.owner16  gravatar.displayName = event.params.displayName17  gravatar.imageUrl = event.params.imageUrl18  gravatar.save()19}

Oups, comme c’est malheureux, quand je déploie mon parfait subgraph dans Subgraph Studio, il échoue avec l’erreur “Gravatar not found!”.

La méthode habituelle pour tenter de résoudre le problème est la suivante :

1. Apportez une modification à la source des mappages, ce qui, selon vous, résoudra le problème (même si je sais que ce ne sera pas le cas).
2. Redéployer le subgraph vers Subgraph Studio (ou un autre Graph Node distant).
3. Attendez qu’il soit synchronisé.
4. S’il se casse à nouveau, revenez au point 1, sinon : Hourra !

Il s’agit en fait d’un processus assez familier à un processus de débogage ordinaire, mais il y a une étape qui ralentit terriblement le processus : 3. Attendez qu’il se synchronise.

L’utilisation du Subgraph forking permet d’éliminer cette étape. Voici à quoi cela ressemble :

0. Créer un Graph Node local avec l’ensemble de base de fork approprié.
1. Apportez une modification à la source des mappings qui, selon vous, résoudra le problème.
2. Déployer sur le Graph Node local, forking du Subgraph Défaillant et à partir du bloc problématique.
3. S’il casse à nouveau, revenez à 1, sinon : Hourra !

Maintenant, vous pouvez avoir 2 questions :

1. base de fourche quoi ???
2. Fourcher qui ?!

Je réponds :

1. fork-base est l’URL “de base”, de sorte que lorsque l’id du subgraph est ajouté, l’URL résultante (<fork-base>/<subgraph-id>) est un endpoint GraphQL valide pour le store du subgraph.
2. Fourcher est facile, pas besoin de transpirer :

1$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020

N’oubliez pas non plus de définir le champ dataSources.source.startBlock dans le manifeste Subgraph au numéro du bloc problématique, afin d’éviter d’indexer des blocs inutiles et de profiter du fork !

Voici donc ce que je fais :

1. Je démarre un Graph Node local (voici comment faire⁠) avec l’option fork-base fixée à : https://api.thegraph.com/subgraphs/id/, puisque je vais créer un subgraph, le subgraph bogué que j’ai déployé plus tôt, à partir de Subgraph Studio.

1$ cargo run -p graph-node --release -- \2     --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \3     --ethereum-rpc NOM_RÉSEAU : [CAPABILITIES] :URL \4     --ipfs 127.0.0.1:50015     --fork-base https://api.thegraph.com/subgraphs/id/

2. Après une inspection minutieuse, j’ai remarqué qu’il y avait un décalage dans les représentations id utilisées lors de l’indexation des Gravatars dans mes deux handlers. Alors que handleNewGravatar le convertit en hexadécimal (event.params.id.toHex()), handleUpdatedGravatar utilise un int32 (event.params.id.toI32()) ce qui fait paniquer handleUpdatedGravatar avec “Gravatar not found!”. Je fais en sorte qu’ils convertissent tous les deux l’id en hexadécimal.
3. Après avoir fait les changements, je déploie mon Subgraph sur le Graph Node local, forking du Subgraph défaillant et configurer dataSources.source.startBlock à 6190343 dans subgraph.yaml :

1$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020

4. J’inspecte les logs générés par le Graph Node local et, Hourra!, tout semble fonctionner.
5. Je déploie mon subgraph maintenant exempt de bugs vers un Graph Node distant et je vis heureux jusqu’à la fin des temps !