[Lake] Issue-481: Adding Payouts to the Data Factory

[kdetry]

Fixes #481

Changes proposed in this PR:

• Added Payouts schema
• Created fetching process for payouts
• Added fn to fetch payouts from subgraph
• Added mocks and tests

[codeclimate]

Code Climate has analyzed commit 2ffb490 and detected 3 issues on this pull request.

Here's the issue category breakdown:

Category	Count
Complexity	3

The test coverage on the diff in this pull request is 98.4% (50% is the threshold).

This pull request will bring the total coverage in the repository to 95.2% (0.1% change).

View more on Code Climate.

[idiom-bytes]

I'm not sure why this has to be looped... it should already be a list[str] of addresses that can be embedded into the query.

We should be able to use a single where clause for subgraph, which may perhaps reduce the search/query time (and it's easier to read). Example:

That generates the following query for multiple assets

query {
            predictPayouts (
            first: 10
            skip: 1
            where: {
        {
            timestamp_gte: 1622547000,
            timestamp_lte: 1622548800,
            prediction_contains: ['0x18f54cc21b7a2fdd011bea06bba7801b280e3151', '0x33334cc21b7a2fdd011bea06bba7801b280e3151']
        }
    }
        ) {
                id
                timestamp
                payout
                prediction {
                    user {
                        id
                    }
                    slot {
                        id
                        predictContract{
                            id
                            token{
                                name
                            }
                        }
                    }
                }
            }
        }

as defined in this test example

[kdetry]

I took another look at your comment, @idiom-bytes. The "aaset_ids" argument is a list of strings that represent the IDs of the contracts we want to retrieve. Unfortunately, the "predictPayouts" query's "where" clause does not have a contract filter. We could use a nested query, like the one below, but our subgraph system does not allow it:

where: {
    prediction_: {
        slot_: {
            predictContract_in: ["0xfeed1", "0xfeed2"]
        }
    }
}

However, the "prediction_contains" argument searches for text within prediction IDs. It only allows strings. The structure of a prediction ID is as follows:

{contract address}-{slot}-{user}

Therefore, if the contract address is present in the prediction ID, we can retrieve it.

[KatunaNorbert]

Looked into this and I agree with @kdetry, we can't just pass the list of addresses with the way subgraph it's structured right now

[idiom-bytes]

Please make sure that we're retrieving all required data to generate the insights we want. Payout event is where a lot of the stake/revenue/prediction values are provided. Example:

• predictedValue
• prediction.slot.revenue
• prediction.stake
• prediction.slot.roundSumStakesUp
• prediction.slot.roundSumStakes

So, we need to fetch this additional data such that we can update our local records.

We can then use the data from the payout event to update our lake/ pdr_predictions and pdr_slots tables.

query{  
  predictPayouts(...){
    prediction{
      slot {
        id
        predictContract {
          id
        }
        slot
        status
        revenue
        roundSumStakesUp
        roundSumStakes
      }
      user {
        id
      }
      stake
    }
    payout
    predictedValue
    trueValue
    timestamp
  }
}```

I have tried to put some of this in the `lake.html` file, but that's not an exhaustive set of requirements. All data relating to `stake/revenue/prediction` outcome should be retrieved.

To better understand what each contract event provides, you can check the contract for the event, or the subgraph event handler to see what data the subgraph updates/yields as a result of the contract event.

[kdetry]

#447
I have followed the BRONZE_FOR_PAYOUTS table on the epic so I didn't add these values.

I am going to add them asap.

[KatunaNorbert]

Do we need to keep this commented lines?

[kdetry]

I close this PR, it is replaced with the following ne:
#559