ethereum/clrfund

Subgraph timeout error when deployed to `arbitrum-rinkeby`

pettinarip opened this issue · 5 comments

We've deployed the subgraph into the Hosted Service for testing purposes in the arbitrum-rinkeby network https://api.thegraph.com/subgraphs/name/pettinarip/clr-rinkarby

This is the error message we get when it is deployed:

failed to process trigger: block #4816732 (0x2793…2563), transaction 0bd19867d96ea9ac2aa12fa337044b7f19272ff87c255f77246f41cbf3621896: Handler 'handleRoundStarted' hit the timeout of '600' seconds: wasm trap: interrupt\twasm backtrace:\t    0: 0xffffffff - <unknown>!~lib/@graphprotocol/graph-ts/chain/ethereum/ethereum.Value#toAddress\t    1: 0x1b14 - <unknown>!src/FundingRoundFactoryMapping/handleRoundStarted\t

It looks like the handleRoundStarted is doing a lot of things and we should need to optimize it.

Note: I've tested deploying a "lighter" version of this handler (where I'm only indexing the necessary data we need for our current use cases) and it worked fine.

To be clear, @pettinarip this "lighter" version of the handler - would it provide enough of what we need to run the Eth2 CLR round? Or is this a blocker?

To be clear, @pettinarip this "lighter" version of the handler - would it provide enough of what we need to run the Eth2 CLR round? Or is this a blocker?

Yes. I don't have the exact version I deployed but it had all the necessary data that we needed at that moment. I'll deploy a new instance to rinkarby to test the MACI scripts so I'll test this again and see if this is still happening.

If it happens again, I'll share the exact handler I'm using just in case.

Update: @pettinarip has since been able to deploy the full subgraph 3 times on RinkArby w/ no errors. Perhaps this was a temp issue that's since been fixed?

Closing since we can't reproduce this error anymore. I have deployed a new instance of the subgraph into rinkarby and it didn't throw any error.