Simple Subgraph Integration Testing Proposal

Questions & Feedback Feedback
1

This is a follow on from the Unit Testing in AssemblyScript thread, based on discussions with @fubhy and @AxiomaticAardvark.

A common occurrence with subgraph development is that a live subgraph will fail as of a given block, often due to some unforeseen situation or circumstance. The current workflow requires fixing the bug in the subgraph, redeploying the subgraph, and waiting for indexing to complete up to the same block (to see if the fix worked). This is time-consuming, and frustrating if the fix does not work first time.

The proposed solution is to allow running handlers on a single block for a locally built subgraph, using a subgraph URL as the “store” (this URL could be from the failed subgraph instance).

Illustrative cli:

graph build
graph process-block --blockNumber 123456 --store https://api.thegraph.com/subgraphs/name/enzymefinance/enzyme-kovan --rpc <ethereum_node>

Some considerations:

  • This may need specifically created logging (assuming that graph-node logging would not be available)
  • If there are multiple handlers in a block, then the state would need to be handled appropriately (based on the graph node endpoint & any loaded / saved entities during the block)
  • The specified ethereum node would need to be archival if the subgraph requires contract calls

It would be great to get feedback on this problem area, and proposed approach (this has been slated as a follow-on for the Limechain team, who are currently working on the Unit Testing framework) cc @dennison @Brendan @ianlapham @Leo

6 Likes
2

I like it. Conceptually it’s like ‘forking’ a subgraph from a certain block number. As long as the graph node is able to use state across the remote fork and the local updates, I think it could work.

3 Likes
3

The first version of this has been merged, and will be in the next Graph Node release! Great work by Limechain on this (it has become precisely “forking”, as you described Brendan)

2 Likes