Subgraph Stopped?

[kosso]

The syncing of the Subgraph hosted at The Graph https://thegraph.com/hosted-service/subgraph/uniswap/uniswap-v2?selected=logs appears to have stopped. (see debug tab)

12/05/2023, 20:37:13 - Subgraph stopped, WASM runtime thread terminated

Any ideas when this might be back up and running again?

[kosso]

The sync is still stopped, days later.
Is this service going to be returning?

Or should we look for alternative sources of data? This is quite frustrating.

[Lanskih90]

I found a few more subgraphs on thegraph.com, and they have the same problem with sync. It seems to me that there is some kind of global problem with block sync :((

[kosso]

It appears that they restarted the sync on the UniswapV2 subgraph yesterday.
It's still catching up the syncing.
Currently got as far as somewhere around Sunday 4am UK time.

I also use the blocklytics/ethereum-blocks Subgraph. That seems to be all up to date.

[Lanskih90]

I'm using uniswap/uniswap-v2 and ianlapham/uniswapv2 to get data for pairs of pools, and I see that they are not synchronized -2 days, I did not find other options ...

[kosso]

Right. I use the ianlapham version as a backup too. I see that restarted syncing yesterday too.
It also appears to have got as far as Sun May 14 2023 04:22:35 GMT+0100, and still syncing.

[Lanskih90]

How long will it sync to real time ?
I see that it periodically falls and then restarts. Yesterday there was a sync delay of -2 days, todays the same...

[bhayward93]

It seems that there is another issue with the subgraph - are there any official channels where I can get updated on status, short of scraping through Discord occasionally?

[finnmeier23]

any news on this?

[hung-native]

bump

[bullish-moonrock]

Why is the last synced blocked in May? It is one month behind the current block, when will this be fixed? Are there any alternatives?

[kosso]

Try this dev version, which seems to be working and staying up to date :
https://thegraph.com/hosted-service/subgraph/ianlapham/uniswap-v2-dev

[coelrex]

bump

[jotto]

Possible fix in the ian/overflow-fix branch (could we merge it? @ianlapham), and steps I took (which may be wrong) for updating a local graph-node with the new code:

1. git clone https://github.com/Uniswap/v2-subgraph.git
2. git switch ian/overflow-fix
3. I had to delete yarn.lock because yarn was failing with broken deps (maybe they were unneeded?), then ran yarn again, and yarn codegen
4. the subgraph.yaml graft section of this branch has the correct block number to graft from to fix this bug, but you may need to edit the base field to point your actual subgraph ID, as described here: https://ethereum.stackexchange.com/a/143648
5. ./node_modules/.bin/graph deploy davekaj/uniswap --debug --ipfs http://localhost:5001 --node http://127.0.0.1:8020 (modify --ipfs and --node flags as appropriate)
6. restart graph-node
7. behind the scenes, graph-node/postgres should be copying data from the broken subgraph (up to the blocknumber in subgraph.yaml graft) - monitor progress in graph-node database, subgraphs schema, copy_table_state table

--

The Postgres data copy will take hours/days, I'm curious if anyone knows a way or quick/dirty hack to update the subgraph code without "grafting" (copying) the uniswap-v2 subgraph data (which is about 700GB).

--

Ian's branch was discovered by browsing https://github.com/Uniswap/v2-subgraph/network, shift+right arrow to go to the end, then left arrow to go backwards while hovering over the dots to find bug fixes

--

actual error from graph-node database, subgraphs schema, subgraph_error table:

Mapping aborted at ~lib/@graphprotocol/graph-ts/index.ts, line 324, column 8, with message: overflow converting 0x0000000000000000000000000000000000000000000000000000000067e53c31 to u32 wasm backtrace: 0: 0x1c54 - !<wasm function 81> 1: 0x1d63 - !<wasm function 82> 2: 0x1d93 - !<wasm function 83> 3: 0x1dbe - !<wasm function 84> 4: 0x2141 - !<wasm function 97>

[jotto]

Update, 4 days later:

The total time to graft ianlapham's branch of the uniswap v2 subgraph was 4 days, and it failed with the same error.

2 problems with the previous approach:

1. the branch in question ian/overflow-fix is partially fixed but is missing (at least) the same fix for fetchTokenDecimals
2. even though that branch is missing a fix, the hosted subgraph https://thegraph.com/hosted-service/subgraph/ianlapham/uniswap-v2-dev is correctly syncing and pointed to IPFS QmXYAmabbEmnSDNR5GWJhmm2NQKXnPkSJEBC3EsMwjXr4e. But trying to use this content hash by updating the subgraph SQL also fails because the content doesn't appear to be on IPFS as of 2023-08-28 (just times out).

Quick/dirty/dangerous hack fix that worked for me without grafting:

1. git clone https://github.com/Uniswap/v2-subgraph.git
2. git switch ian/overflow-fix
3. apply the following git diff

diff --git a/src/mappings/helpers.ts b/src/mappings/helpers.ts
index b5fd836..7774ccb 100644
--- a/src/mappings/helpers.ts
+++ b/src/mappings/helpers.ts
@@ -134,6 +134,10 @@ export function fetchTokenTotalSupply(tokenAddress: Address): BigInt {
 }
 
 export function fetchTokenDecimals(tokenAddress: Address): BigInt {
+  if (SKIP_TOTAL_SUPPLY.includes(tokenAddress.toHexString())) {
+    return BigInt.fromI32(0)
+  }
+
   // static definitions overrides
   let staticDefinition = TokenDefinition.fromAddress(tokenAddress)
   if (staticDefinition != null) {

4. run ./node_modules/.bin/graph build --ipfs http://localhost:5001 --node http://127.0.0.1:8020 to upload the subgraph manifest to IPFS

5. run the following SQL after finding "QmXYAmabbEmnSDNR5GWJhmm2NQKXnPkSJEBC3EsMwjXr4e" and replacing in the SQL code below with the content hash of your existing uni v2 subgraph (may need to find/replace "7507e562bea1b434c37d29df3a02fa11" if it differs in your setup)

UPDATE "subgraphs"."subgraph_features" SET "id"='QmSRB7XjkL6JHZSsfDibjSFhurkuSdE7H8vcrVZHJpfLry' WHERE "id"='QmXYAmabbEmnSDNR5GWJhmm2NQKXnPkSJEBC3EsMwjXr4e';
UPDATE "public"."deployment_schemas" SET "subgraph"='QmSRB7XjkL6JHZSsfDibjSFhurkuSdE7H8vcrVZHJpfLry' WHERE "subgraph"='QmXYAmabbEmnSDNR5GWJhmm2NQKXnPkSJEBC3EsMwjXr4e';
UPDATE "subgraphs"."subgraph_version" SET "deployment"='QmSRB7XjkL6JHZSsfDibjSFhurkuSdE7H8vcrVZHJpfLry' WHERE "subgraph"='7507e562bea1b434c37d29df3a02fa11';
DELETE FROM "subgraphs"."subgraph_error" WHERE subgraph_id='QmXYAmabbEmnSDNR5GWJhmm2NQKXnPkSJEBC3EsMwjXr4e';
UPDATE "subgraphs"."subgraph_deployment" SET "deployment"='QmSRB7XjkL6JHZSsfDibjSFhurkuSdE7H8vcrVZHJpfLry',"fatal_error"=NULL, "health"='healthy', "failed"=false, "synced"=true WHERE "deployment"='QmXYAmabbEmnSDNR5GWJhmm2NQKXnPkSJEBC3EsMwjXr4e';

5. restart your graph-node, and uniswap v2 subgraph should now be syncing