The Arbitrators are contacting Indexer address 0x9082f497bdc512d08ffde50d6fce28e72c2addcf and fisherman 0xfe56931ed1cd3021ef1162bae2b3872e8694d1da for a new dispute filed in the protocol.
Fisherman, could you share the insights or data you gathered that led to you filing the dispute? Please provide all relevant information and records about the open dispute. This will likely include POIs generated for the affected subgraph(s).
About the Procedure
The Arbitration Charter regulates the arbitration process. You can find it in Radicle project ID rad:git:hnrkrhnth6afcc6mnmtokbp4h9575fgrhzbay or at GIP-0009: Arbitration Charter.
Hi @tmigone, this is 0xfe56931ed1cd3021ef1162bae2b3872e8694d1da,
This dispute concerns the indexer 0x9082f497bdc512d08ffde50d6fce28e72c2addcf closing subgraph that was not synced 100%. The indexer only synced up to block number around 88610000, while the correct startBlock should have been 321468804 epoch 853.
According to #GDR-33 and #GDR-34, 0x9082f497bdc512d08ffde50d6fce28e72c2addcf indexer reports a database failure on April 12. The indexer took at least 22 days to sync based on the first allocation opened on February 24 and closed on March 18.
Today is April 24 which is 12 days and the indexer is nowhere near half synced.
Can you please clarify what is the actual fault for the dispute?
By March 31st, 2025 when we closed the last allocation on this subgraph we had it fully synced and the POI is a valid one.
On April 12, 2025 we had a database failure which means we had to resync all of our subgraphs. This is a heavy subgraph, taking up 234GB so far and still syncing.
I don’t see any relation with syncing speed and validity of a POI. We might have started syncing offchain before the first allocation. Syncing speed can also be affected by the RPC provider (we are using Pinax for Arbitrum). Can you please expand on your observation?
Using the time or day difference as a measure to gauge whether the disputed indexer is progressing isn’t the most reliable approach. One could also argue that after a database failure and resyncing all subgraphs from scratch, the load becomes significantly heavier compared to when the indexer initially started syncing the subgraph.
From the last check, @megatron was synced up to block around 88610000 which was almost two years ago. It took @megatron at least 22 days to sync 100%. Now 13 days after the database failure, the subgraph is only about 30% synced.
If @megatron started syncing at the same time the allocation was created then the current progress seems illogical. If offchain syncing method was used, are there any graph-node logs or grafana chart logs from the past two months that can be provided to support this statement?
@Inspector_POI You’ve filed two disputes for the same indexer @megatron, just wondering what led to the change in your approach toward my disputes? @megatron agreed to provide logs from the failed database for @Inspector_POI’s disputes. I hope to see the same here.
There hasn’t been any change in my approach. Just because I mentioned this as not the most reliable method doesn’t mean I’m siding with the disputed indexer.
As stated in all my previous disputes,
I’ve approached this matter with neutrality, aiming to gather and analyze all relevant facts to determine whether the issue stems from a software malfunction or an operational oversight by the indexer.
The disputed indexer has been cooperative so far by providing all the requested logs for MY disputes, which certainly adds credibility to his claim.
You are the fisherman for THIS dispute, whatever logs or necessary materials are required, it’s YOUR / Arbitration Team’s responsibility to request them.
Please do not conflate this with my disputes or my requirements.
Below you can find the indexer agent logs related to the syncing start date of the subgraph and the table data from the live database and the crashed one.
Index Agent Logs
{"level":30,"time":1739325004291,"pid":1,"hostname":"9e2ae438aa23","name":"IndexerAgent","component":"GraphNode","name":"indexer-agent/XoywU9ze3d","deployment":{"bytes32":"0xeb5c9b1960366a59bd64f7db97692c2bb24e01662be4a5f09b0d995781a19594","ipfsHash":"QmeBQRHngJLJ2r84Vvp3mgKbgYXHmAqc3dWkXoywU9ze3d"},"msg":"Successfully deployed subgraph deployment"}
{"level":30,"time":1739325003354,"pid":1,"hostname":"9e2ae438aa23","name":"IndexerAgent","component":"GraphNode","name":"indexer-agent/XoywU9ze3d","deployment":{"bytes32":"0xeb5c9b1960366a59bd64f7db97692c2bb24e01662be4a5f09b0d995781a19594","ipfsHash":"QmeBQRHngJLJ2r84Vvp3mgKbgYXHmAqc3dWkXoywU9ze3d"},"msg":"Deploy subgraph deployment"}
{"level":20,"time":1739325003347,"pid":1,"hostname":"9e2ae438aa23","name":"IndexerAgent","component":"GraphNode","name":"indexer-agent/XoywU9ze3d","deployment":"QmeBQRHngJLJ2r84Vvp3mgKbgYXHmAqc3dWkXoywU9ze3d","msg":"Subgraph deployment not found, creating subgraph name and deploying..."}
After reviewing the evidence and considering the information available we have decided to resolve this dispute as a draw. The disputed indexer’s activity is in line with the operational failure they have described. We don’t see any reason to believe the POI they presented is invalid nor that the subgraph was not fully synced at the moment the associated allocation was closed. Indexer’s status endpoint provides valuable information related to current subgraph deployments, it should not be used to derive information for previous deployment syncing attempts.
We appreciate the fisherman’s thoroughness and everyone’s patience on this dispute. We’ll be posting the transaction shortly.