फोर्क्स का उपयोग करके त्वरित और आसान सबग्राफ डिबगिंग

जैसा कि कई प्रणालियों में बड़े पैमाने पर डेटा प्रोसेसिंग के दौरान होता है, The Graph के Indexers (Graph Nodes) को आपके सबग्राफ को लक्षित ब्लॉकचेन के साथ सिंक करने में काफी समय लग सकता है। डिबगिंग के उद्देश्य से त्वरित परिवर्तन करने और Indexing के लिए आवश्यक लंबे इंतजार के बीच का अंतर अत्यधिक प्रतिकूल होता है, और हम इस समस्या से भली-भांति परिचित हैं। इसी कारण हम सबग्राफ फॉर्किंग पेश कर रहे हैं, जिसे LimeChain⁠ द्वारा विकसित किया गया है, और इस लेख में मैं आपको दिखाऊंगा कि इस फीचर का उपयोग करके Subgraph डिबगिंग को काफी तेज़ कैसे किया जा सकता है!

ठीक है वो क्या है?

सबग्राफ फॉर्किंग वह प्रक्रिया है जिसमें आलसी तरीके से किसी दूसरे सबग्राफ के स्टोर (आमतौर पर एक रिमोट स्टोर) से entities को लाया जाता है।

सबग्राफ फॉर्किंग आपको अपने असफल सबग्राफ को ब्लॉक X पर डिबग करने की अनुमति देता है बिना ब्लॉक X तक सिंक होने का इंतजार किए।

क्या?! कैसे?

जब आप एक सबग्राफ को रिमोट ग्राफ-नोड पर indexing के लिए डिप्लॉय करते हैं और यह ब्लॉकXपर फेल हो जाता है, तो अच्छी खबर यह है कि ग्राफ नोड अभी भी अपनी स्टोर का उपयोग करके GraphQL क्वेरीज़ को सर्व करेगा, जो ब्लॉकX तक सिंक है। यह बहुत बढ़िया है! इसका मतलब है कि हम इस “अप-टू-डेट” स्टोर का लाभ उठा सकते हैं ताकि ब्लॉकXको indexing करते समय उत्पन्न होने वाली बग्स को ठीक किया जा सके।

हम एक विफल हो रहे सबग्राफ को एक दूरस्थ ग्राफ-नोड से fork करने जा रहे हैं, जो निश्चित रूप से ब्लॉक X तक सबग्राफ को इंडेक्स कर चुका है, ताकि डिबग किए जा रहे स्थानीय रूप से तैनात सबग्राफ को ब्लॉकXपर इंडेक्सिंग स्थिति का अद्यतन दृश्य प्रदान किया जा सके।

कृपया मुझे कुछ कोड दिखाओ!

सुबग्राफ डिबगिंग पर ध्यान केंद्रित रखने के लिए, चलिए चीजों को सरल रखते हैं और example-सबग्राफ⁠ के साथ चलते हैं, जो Ethereum Gravity स्मार्ट contract को indexing कर रहा है।

यहां Gravatars को indexing करने के लिए handler परिभाषित किए गए हैं, जिनमें कोई बग नहीं है:

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 not found!', [])13    return14  }15  gravatar.owner = event.params.owner16  gravatar.displayName = event.params.displayName17  gravatar.imageUrl = event.params.imageUrl18  gravatar.save()19}

अरे, कितनी दुर्भाग्यपूर्ण बात है, जब मैं अपना पूरी तरह से सही दिखने वाला सबग्राफ सबग्राफ Studio पर डिप्लॉय करता हूँ, तो यह*“Gravatar not found!”* त्रुटि के साथ फेल हो जाता है।

फिक्स का प्रयास करने का सामान्य तरीका है:

1. मैपिंग सोर्स में बदलाव करें, जो आपको लगता है कि समस्या का समाधान करेगा (जबकि मुझे पता है कि यह नहीं होगा)।
2. सबग्राफ को सबग्राफ Studio (या किसी अन्य remote ग्राफ-नोड) पर फिर से डिप्लॉय करें।
3. इसके सिंक-अप होने की प्रतीक्षा करें।
4. यदि यह फिर से टूट जाता है तो 1 पर वापस जाएँ, अन्यथा: हुर्रे!

यह वास्तव में एक सामान्य डिबग प्रक्रिया के समान है, लेकिन इसमें एक कदम है जो प्रक्रिया को बहुत धीमा कर देता है: _3. इसके सिंक होने का इंतजार करें.

सबग्राफ फॉर्किंग का उपयोग करके, हम मूल रूप से इस चरण को समाप्त कर सकते हैं। यह इस प्रकार दिखता है:

0. लोकल ग्राफ-नोड को सेट appropriate fork-base के साथ चालू करें।
1. मैपिंग सोर्स में परिवर्तन करें, जिसके बारे में आपको लगता है कि इससे समस्या हल हो जाएगी.
2. स्थानीय ग्राफ-नोड पर डिप्लॉय करें, असफल हो रहे सबग्राफ को फोर्क करते हुए और समस्या वाले ब्लॉक से प्रारंभ करते हुए।
3. यदि यह फिर से ब्रेक जाता है, तो 1 पर वापस जाएँ, अन्यथा: हुर्रे!

अब, आपके 2 प्रश्न हो सकते हैं:

1. फोर्क-बेस क्या???
2. फोर्किंग कौन?!

और मैं उत्तर देता हूं:

1. fork-base “मूल” URL है, जिससे जब subgraph id जोड़ी जाती है, तो परिणामी URL (<fork-base>/<subgraph-id>) उस सबग्राफ के स्टोर के लिए एक वैध GraphQL एंडपॉइंट बन जाता है।
2. फोर्किंग आसान है, पसीना बहाने की जरूरत नहीं:

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

इसके अलावा, सबग्राफ manifest में dataSources.source.startBlock फ़ील्ड को समस्या वाले ब्लॉक की संख्या पर सेट करना न भूलें, ताकि आप गैर-ज़रूरी ब्लॉकों को indexing करने से बच सकें और fork का लाभ उठा सकें!`

तो, यहाँ मैं क्या करता हूँ:

1. मैंने एक लोकल ग्राफ-नोड स्पिन-अप किया (यहाँ देखें कैसे करें)⁠ जिसमें fork-base ऑप्शन को सेट किया: https://api.thegraph.com/subgraphs/id/, क्योंकि मैं एक सबग्राफ को फोर्क करने जा रहा हूँ, जो कि पहले मैंने सबग्राफ Studio पर डिप्लॉय किया था और उसमें बग्स थे।

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

2. सावधानी से निरीक्षण करने के बाद, मुझे पता चलता है कि मेरे दो हैंडलरों में Gravatar के id प्रतिनिधित्व में असंगति है। जबकि handleNewGravatar इसे हेक्स (event.params.id.toHex()) में बदलता है, handleUpdatedGravatar एक int32 (event.params.id.toI32()) का उपयोग करता है, जिससे handleUpdatedGravatar “Gravatar not found!” के साथ पैनिक हो जाता है। मैंने दोनों को id को हेक्स में बदलने के लिए संशोधित किया है।
3. मैंने बदलाव करने के बाद अपने सबग्राफ को लोकल Graph Node पर डिप्लॉय किया, failing सबग्राफ को fork करके और subgraph.yaml में dataSources.source.startBlock को 6190343 पर सेट किया।

1$ 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. मैं अपने अब बग-मुक्त सबग्राफ को एक दूरस्थ ग्राफ-नोड पर तैनात करता हूँ और खुशी-खुशी जीवन व्यतीत करता हूँ! (no potatoes tho)