Fork Kullanarak Hızlı ve Kolay Subgraph Hata Ayıklama

Reading time: 4 min

As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing subgraph forking, developed by LimeChain, and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!

Subgraph forklama, başka bir subgraph'ın deposundan(genellikle uzaktaki birinden) unsurları yavaş bir şekilde getirme işlemidir.

Hata ayıklama bağlamında, subgraph forklama, X bloğunda başarısız olan subgraph'ınızda yine aynı X bloğunun senkronize olmasını beklemeksizin hata ayıklamanıza olanak tanır.

When you deploy a subgraph to a remote Graph Node for indexing and it fails at block X, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block X. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block X.

In a nutshell, we are going to fork the failing subgraph from a remote Graph Node that is guaranteed to have the subgraph indexed up to block X in order to provide the locally deployed subgraph being debugged at block X an up-to-date view of the indexing state.

Subgraph hata ayıklamasında konsantrasyonu bozmamak adına işleri basit tutalım ve Ethereum Gravity akıllı sözleşmesini indeksleyen subgraph örneği ile ilerleyelim.

Burada hiç hata olmadan Gravatarları indekslemek için tanımlanan işleyiciler şunlardır:

export function handleNewGravatar(event: NewGravatar): void {
  let gravatar = new Gravatar(event.params.id.toHex().toString())
  gravatar.owner = event.params.owner
  gravatar.displayName = event.params.displayName
  gravatar.imageUrl = event.params.imageUrl
  gravatar.save()
}

export function handleUpdatedGravatar(event: UpdatedGravatar): void {
  let gravatar = Gravatar.load(event.params.id.toI32().toString())
  if (gravatar == null) {
    log.critical('Gravatar not found!', [])
    return
  }
  gravatar.owner = event.params.owner
  gravatar.displayName = event.params.displayName
  gravatar.imageUrl = event.params.imageUrl
  gravatar.save()
}

Oops, how unfortunate, when I deploy my perfect looking subgraph to Subgraph Studio it fails with the "Gravatar not found!" error.

Genellikle düzeltmeyi denemek için yol şudur:

1. Eşleştirme kaynağında, sorunu çözeceğine inandığınız bir değişiklik yapın (ama ben çözmeyeceğini biliyorum).
2. Re-deploy the subgraph to Subgraph Studio (or another remote Graph Node).
3. Senkronize olması için bekleyin.
4. Tekrar sorunla karşılaşırsanız 1. aşamaya geri dönün, aksi takdirde: Yaşasın!

Bu, sıradan bir hata ayıklama işlemine gerçekten oldukça benzerdir, fakat işlemi korkunç şekilde yavaşlatan bir adım vardır: 3. Senkronize olması için bekleyin.

Aslında subgraph forklama kullanarak bu adımı ortadan kaldırabiliriz. Nasıl göründüğüne bakalım:

0. Spin-up a local Graph Node with the appropriate fork-base set.
1. Eşleştirme kaynağında, sorunu çözeceğine inandığınız bir değişiklik yapın.
2. Deploy to the local Graph Node, forking the failing subgraph and starting from the problematic block.
3. Tekrar sorunla karşılaşırsanız 1. aşamaya geri dönün, aksi takdirde: Yaşasın!

Şimdi, 2 sorunuz olabilir:

1. fork temelli ne???
2. Kimi forkluyoruz?!

Ve ben cevap veriyorum:

1. fork temelli (fork-base) subgraph deposu için geçerli bir GraphQL uç noktası oluşturacak şekilde subgraph kimliği(id) eklendiğinde oluşan URL'ye (<fork-base>/<subgraph-id>) eklenen "temel" bir URL'dir.
2. Forklama kolay, ter dökmeye gerek yok:

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

Ayrıca, subgraph manifestindeki dataSources.source.startBlock alanını sorunlu bloğun numarasına ayarlamayı unutmayın, böylece gereksiz blokları indekslemeyi geçebilir ve forklamanın avantajından yararlanabilirsiniz!

İşte benim ne yaptığım:

1. I spin-up a local Graph Node (here is how to do it) with the fork-base option set to: https://api.thegraph.com/subgraphs/id/, since I will fork a subgraph, the buggy one I deployed earlier, from Subgraph Studio.

$ cargo run -p graph-node --release -- \
    --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
    --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL \
    --ipfs 127.0.0.1:5001
    --fork-base https://api.thegraph.com/subgraphs/id/

2. Dikkatli bir inceleme sonrasında, iki işleyicimdeki Gravatarları indekslerken kullanılan kimlik(id) temsillerinde bir uyuşmazlık oldupunu fark ettim. handleNewGravatar onu bir 16'lık sisteme (event.params.id.toHex()) dönüştürürken, handleUpdatedGravatar, handleUpdatedGravatar'ın "Gravatar not found!" hatası vermesine neden olan bir int32 (event.params.id.toI32()) kullanır. Her ikisinde de kimliğin 16'lık sisteme dönüştürülmesini sağlarım.
3. After I made the changes I deploy my subgraph to the local Graph Node, forking the failing subgraph and setting dataSources.source.startBlock to 6190343 in subgraph.yaml:

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

4. I inspect the logs produced by the local Graph Node and, Hooray!, everything seems to be working.
5. I deploy my now bug-free subgraph to a remote Graph Node and live happily ever after! (no potatoes tho)