Missing liquidity events

[yabirgb]

Hello. For @rotki we have some address selected for testing and before the subgraph fix we could fetch addLiquidityEvents for the address 0x3ba6eb0e4327b96ade6d4f3b578724208a590cef. One of them being https://etherscan.io/tx/0x9b5471ee166bc8210ae10faae6e3292424829e48cb437346fbcc60bd66a5c008

After the last upgrade the query

{
	addLiquidityEvents(where:{provider: "0x3ba6eb0e4327b96ade6d4f3b578724208a590cef" }){
        pool{
        id
        lpToken {
            id
            decimals
        }
        underlyingCoins {
            index
            token {
                id
            }
            balance
        }
        virtualPrice
        name
        }
        tokenAmounts
        fees
        tokenSupply
        timestamp
        transaction
        block
    }
}

doesn't return any event. What could be the issue?

[sistemico]

Seeing this issue. Gonna get back to you as soon I figure it out. Thanks for reporting!

[yabirgb]

Hello @sistemico ! Did you find anything?

[sistemico]

Sorry for the delay to fix this one, but we couldn't take the time to resolve it yet.

[sistemico]

To provide a bit more context on this issue, it happens because so far the subgraph has been ignoring pool events before each pool is registered in the registry contract. We have in mind the necessary fix and we are already working on it, but it requires a little refactoring and additional work to redeploy and test the solution.

[LefterisJP]

Hello @sistemico thank you for providing more context on why this is taking a bit more time to implement. Do you guys have any update? This is a blocker for our curve.fi historical integration which we would really love to have.

[yabirgb]

Hello @sistemico ! Do you have new information about this issue? The repo doesn't seem to have received any commit and subgraphs were not updated recently

[sistemico]

Hey @yabirgb! I'm about to release a bunch of changes in the subgraphs that gonna fix this issue and others, most likely by the end of this week. Will let you know when completed.

[yabirgb]

Hey @yabirgb! I'm about to release a bunch of changes in the subgraphs that gonna fix this issue and others, most likely by the end of this week. Will let you know when completed.

Thank you very much! Will let you know If I find any related error or anything else C:

[yabirgb]

Hello @sistemico ! We haven't seen the subgraph deployed with the fixes. Is it deployed in a new one? (the subgraph shows that the last update was 3 months ago)

[twotimeseleven]

Hi @sistemico, I noticed that the above query only receives information for liquidity transactions for the following signature:

• AddLiquidity(indexed address,uint256[2],uint256[2],uint256,uint256)

Which at the moment doesn't seem to include Metapool transactions. As an example, I believe for this account (random example) we should be seeing 3 total AddLiquidity events, however only two come up. The three events (from oldest to newest) are:

1. https://etherscan.io/tx/0x8b2d34ba5c224044ba876ec29bdfec0c8306dc5804cdd3b4fd070a7aa4b59b57
2. https://etherscan.io/tx/0x000015c6c1b786c803bc9802c21a6a0d34658d409f178d7451368fc9d0259930/advanced
3. https://etherscan.io/tx/0xe8b1b591dbf1193460842b7ef5f6b6b2905794d78b11fd4566efd5e2d50a818a

Where (1) and (2) are indexed, but (3) is not. I suspect that this is an issue with the subgraph.yaml manifest only indexing the above signature (with uint256[2] arrays) and not ones in (3), which have uint256[3] arrays as part of their signature. I think this is the case with metapools. However, inside transaction (3) I also see a regular AddLiquidity event with the correct signature not being picked up (at index 288 of the transaction logs, in the link above), which doesn't seem to be getting picked up either, but I suspect that's because the provider in this log is a Curve.fi contract that's adding liquidity on behalf of the user for the metapool.

Could this be solved by adding another eventHandler to the subgraph manifest for metapools? How might we solve this since providers aren't listed as the original transaction sender for the addition of liquidity?

Looping in @yabirgb as well.

Example query I'm using:

{
  addLiquidityEvents(
    where: {
      provider: "0x97416f4c2088003e3c3d2edd749ae1cffbb6df1c",
    },
    orderBy: block,
    orderDirection: asc
  ) 
  {
    block
    timestamp
    invariant
    pool {
      name
      assetType
      adminFee
      virtualPrice
      isMeta
      coins {
        token {
          name
        }
      }
    }
    provider {
      id
    }
  }	
}

[sistemico]

Hi @Rburdett4, you're right: metapools are currently not properly supported by the subgraph, but I'm gonna do a patch to add the right event handler for metapools as you correctly said. Regarding the issues with regular AddLiquidity event it's most likely a bug in the handler which I'll also address in due course. Thank you very much for taking the time to report and describe the problem in such detail, this will surely speed up the debugging and the solution of the problem.

[twotimeseleven]

@sistemico No problem, very much appreciate the prompt response. I'm really excited about the ability to monitor Curve LP positions, as well as the other capabilities the subgraph offers.

If I may ask, what's your approach to testing this sort of functionality? Are you forking the mainnet into Ganache off a service provider like Alchemy, then simulating your own transactions against that with a local graph-node to check indexing behavior? Or is there a better approach?

Curve is obviously a large operation with thousands of entities, which makes historical debugging a bit tricky. Would love to know your process so that I can test and develop locally alongside you when contributing to this repo.