curvefi / curve-subgraph Goto Github PK

Adapt logic in asset-types.ts and more for tricrypto to produce accurate volumes, prices, etc

I don't think this function is correct, as it sets the pool A to the future A right away (and not only at the given future block).

Unless I am missing something, in which case any help your be appreciated!

Thanks
Marco

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?

When calculating the balance of the underlying coins here the decimals are not used (which causes it default to 18 afaik), one example in which this causes problems is in 3CRV metapools, which causes the balance to be $10^{12}$ times less than the real value. Did not find this issue in the exchangeUnderlying handler

Here is the code of the line with the problem

coin.balance = balances ? decimal.fromBigInt(balances![i]) : decimal.ZERO

Hi, I noticed that the latest registry address has changed to: 0x90E00ACe148ca3b23Ac1bC8C240C2a7Dd9c2d7f5.
If we're looking to handle all pool_added events from both the old and current contract, would we need to add this data source as well?
Thanks.

Opening this issue to let indexers know we're currently aware and investigating the following error, which causes indexing to fail at block 12785713:

{
  "data": {
    "indexingStatusForCurrentVersion": {
      "fatalError": {
        "block": {
          "number": "12785713"
        },
        "handler": null,
        "message": "Heap access out of bounds. Offset: 42 Size: 6291556\twasm backtrace:\t    0: 0x1c74 - <unknown>!generated/schema/Gauge#save\t    1: 0x1dd6 - <unknown>!src/mappings/dao/gauge-controller/handleNewGauge\t in handler `handleNewGauge` at block #12785713 (d64b643a6699097df4b95a36282a9ec776bd89619b32194d44401d5a4e621464)"
      },
      "nonFatalErrors": [],
      "subgraph": "Qma85KVRwTpstXgcHhmufP8Psc54AYKdYfZSrotx89j3jN"
    }
  }
}

We'll ensure a proper fix is found and deployed asap. If you have more info from your own logs don't hesitate to share them below!