From c571bc6ab967f1e4a5008e1df6eb7a4a9d0da24f Mon Sep 17 00:00:00 2001 From: shiyasmohd Date: Fri, 14 Jun 2024 08:02:18 +0530 Subject: [PATCH 1/4] docs: added declared eth_call --- .../en/developing/creating-a-subgraph.mdx | 23 +++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/website/pages/en/developing/creating-a-subgraph.mdx b/website/pages/en/developing/creating-a-subgraph.mdx index b74d1fce8703..5a4309825ab9 100644 --- a/website/pages/en/developing/creating-a-subgraph.mdx +++ b/website/pages/en/developing/creating-a-subgraph.mdx @@ -1154,6 +1154,29 @@ eventHandlers: Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead. +## Declared eth_call + +Reducing `eth_call` definitely improves indexing speed. For `eth_calls` that cannot be eliminated, they can be declared in the subgraph manifest to be processed in parallel with the block processing. +When `graph-node` processes a block, it performs all declared `eth_calls` in parallel before handlers are run where as `eth_calls` that are not declared are executed sequentially when handlers run. This helps reducing total time spent on `eth_calls` and improves indexing speed. + +> **Note:** [SpecVersion](#specversion-releases) >= `1.2.0` is required. Currently, `eth_calls` can only be declared for event handlers. + +### Example Configuration in Subgraph Manifest + +```yaml +event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed) +handler: handleTransferWithPool +calls: + ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to) +``` + +In the example above, the `ERC20.poolInfo` is declared `eth_call`. The text before colon(`ERC20.poolInfo`) is the label for this `eth_call` which is used when logging errors. +The text after colon(`ERC20[event.address].getPoolInfo(event.params.to)`) is the actual `eth_call` that will be executed which is in the form of `Contract[address].function(arguments)`. +Permissible values for `address` and `arguments` are `event.address` and `event.params.` respectively. + +When declared `eth_calls` are used, `graph-node` caches the results in the memory and when the `eth_call` is triggered inside handlers, it fetches the result from the cache instead of making an actual RPC call. + + ## Experimental features Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below: From 308133c747d8eece7ba68f4aa50d63e426b3b617 Mon Sep 17 00:00:00 2001 From: shiyasmohd Date: Fri, 14 Jun 2024 08:31:05 +0530 Subject: [PATCH 2/4] fix: prettier fixes --- website/pages/en/developing/creating-a-subgraph.mdx | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/website/pages/en/developing/creating-a-subgraph.mdx b/website/pages/en/developing/creating-a-subgraph.mdx index 5a4309825ab9..aea59384447c 100644 --- a/website/pages/en/developing/creating-a-subgraph.mdx +++ b/website/pages/en/developing/creating-a-subgraph.mdx @@ -1156,8 +1156,7 @@ Inside the handler function, the receipt can be accessed in the `Event.receipt` ## Declared eth_call -Reducing `eth_call` definitely improves indexing speed. For `eth_calls` that cannot be eliminated, they can be declared in the subgraph manifest to be processed in parallel with the block processing. -When `graph-node` processes a block, it performs all declared `eth_calls` in parallel before handlers are run where as `eth_calls` that are not declared are executed sequentially when handlers run. This helps reducing total time spent on `eth_calls` and improves indexing speed. +Reducing `eth_call` definitely improves indexing speed. For `eth_calls` that cannot be eliminated, they can be declared in the subgraph manifest to be processed in parallel with the block processing. When `graph-node` processes a block, it performs all declared `eth_calls` in parallel before handlers are run where as `eth_calls` that are not declared are executed sequentially when handlers run. This helps reducing total time spent on `eth_calls` and improves indexing speed. > **Note:** [SpecVersion](#specversion-releases) >= `1.2.0` is required. Currently, `eth_calls` can only be declared for event handlers. @@ -1170,13 +1169,10 @@ calls: ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to) ``` -In the example above, the `ERC20.poolInfo` is declared `eth_call`. The text before colon(`ERC20.poolInfo`) is the label for this `eth_call` which is used when logging errors. -The text after colon(`ERC20[event.address].getPoolInfo(event.params.to)`) is the actual `eth_call` that will be executed which is in the form of `Contract[address].function(arguments)`. -Permissible values for `address` and `arguments` are `event.address` and `event.params.` respectively. +In the example above, the `ERC20.poolInfo` is declared `eth_call`. The text before colon(`ERC20.poolInfo`) is the label for this `eth_call` which is used when logging errors. The text after colon(`ERC20[event.address].getPoolInfo(event.params.to)`) is the actual `eth_call` that will be executed which is in the form of `Contract[address].function(arguments)`. Permissible values for `address` and `arguments` are `event.address` and `event.params.` respectively. When declared `eth_calls` are used, `graph-node` caches the results in the memory and when the `eth_call` is triggered inside handlers, it fetches the result from the cache instead of making an actual RPC call. - ## Experimental features Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below: From e3406aaaa48c2720ecbe68cf9333718245e03e92 Mon Sep 17 00:00:00 2001 From: shiyasmohd Date: Fri, 14 Jun 2024 16:50:37 +0530 Subject: [PATCH 3/4] docs: update wordings address & arguments passed --- website/pages/en/developing/creating-a-subgraph.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/pages/en/developing/creating-a-subgraph.mdx b/website/pages/en/developing/creating-a-subgraph.mdx index aea59384447c..f005d73c70b6 100644 --- a/website/pages/en/developing/creating-a-subgraph.mdx +++ b/website/pages/en/developing/creating-a-subgraph.mdx @@ -1169,7 +1169,7 @@ calls: ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to) ``` -In the example above, the `ERC20.poolInfo` is declared `eth_call`. The text before colon(`ERC20.poolInfo`) is the label for this `eth_call` which is used when logging errors. The text after colon(`ERC20[event.address].getPoolInfo(event.params.to)`) is the actual `eth_call` that will be executed which is in the form of `Contract[address].function(arguments)`. Permissible values for `address` and `arguments` are `event.address` and `event.params.` respectively. +In the example above, the `ERC20.poolInfo` is declared `eth_call`. The text before colon(`ERC20.poolInfo`) is the label for this `eth_call` which is used when logging errors. The text after colon(`ERC20[event.address].getPoolInfo(event.params.to)`) is the actual `eth_call` that will be executed which is in the form of `Contract[address].function(arguments)`. The `address` and `arguments` can be replaced with actual values or variables which will be available when executing the handler. When declared `eth_calls` are used, `graph-node` caches the results in the memory and when the `eth_call` is triggered inside handlers, it fetches the result from the cache instead of making an actual RPC call. From 792b41d5a46b5cbf2a8b94c30f640218a8f109ab Mon Sep 17 00:00:00 2001 From: shiyasmohd Date: Fri, 14 Jun 2024 18:20:35 +0530 Subject: [PATCH 4/4] fix: fixed wordings --- website/pages/en/developing/creating-a-subgraph.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/pages/en/developing/creating-a-subgraph.mdx b/website/pages/en/developing/creating-a-subgraph.mdx index f005d73c70b6..d2ffd46cc0e3 100644 --- a/website/pages/en/developing/creating-a-subgraph.mdx +++ b/website/pages/en/developing/creating-a-subgraph.mdx @@ -1169,7 +1169,7 @@ calls: ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to) ``` -In the example above, the `ERC20.poolInfo` is declared `eth_call`. The text before colon(`ERC20.poolInfo`) is the label for this `eth_call` which is used when logging errors. The text after colon(`ERC20[event.address].getPoolInfo(event.params.to)`) is the actual `eth_call` that will be executed which is in the form of `Contract[address].function(arguments)`. The `address` and `arguments` can be replaced with actual values or variables which will be available when executing the handler. +In the example above, the `ERC20.poolInfo` is declared `eth_call`. The text before colon(`ERC20.poolInfo`) is the label for this `eth_call` which is used when logging errors. The text after colon(`ERC20[event.address].getPoolInfo(event.params.to)`) is the actual `eth_call` that will be executed which is in the form of `Contract[address].function(arguments)`. The `address` and `arguments` can be replaced with variables which will be available when executing the handler. When declared `eth_calls` are used, `graph-node` caches the results in the memory and when the `eth_call` is triggered inside handlers, it fetches the result from the cache instead of making an actual RPC call.