graphprotocol / mission-control-indexer

Technical indexer documentation and infrastructure templates for the Mission Control testnet
21 stars 4 forks source link

Bug: Incorrect Allocated GRT numbers in Explorer UI #67

Open crypt1d opened 4 years ago

crypt1d commented 4 years ago

Allocated GRT numbers are 2x bigger than in reality:

image

But I've only allocated 150:

Indexing Rules
┌────────────────────────────────────────────────┬──────────────────┬─────────────────────┬─────────────────────────┬───────────┬───────────┬──────────┬─────────────────────┬────────┐
│ deployment                                     │ allocationAmount │ parallelAllocations │ maxAllocationPercentage │ minSignal │ maxSignal │ minStake │ minAverageQueryFees │ custom │
├────────────────────────────────────────────────┼──────────────────┼─────────────────────┼─────────────────────────┼───────────┼───────────┼──────────┼─────────────────────┼────────┤
│ QmWTrJJ9W8h3JE19FhCzzPYsJ2tgXZCdUqnbyuo64ToTBN │ 50.0             │ 2                   │                         │           │           │          │                     │        │
├────────────────────────────────────────────────┼──────────────────┼─────────────────────┼─────────────────────────┼───────────┼───────────┼──────────┼─────────────────────┼────────┤
│ QmdbHP5ALcHda6UdCtZLYEwQJo7xTKKgUXMwMLLiCspYFE │ 100.0            │ 2                   │                         │           │           │          │                     │        │
├────────────────────────────────────────────────┼──────────────────┼─────────────────────┼─────────────────────────┼───────────┼───────────┼──────────┼─────────────────────┼────────┤
│ global                                         │ 0.01             │ 2                   │                         │           │           │          │                     │        │

I'm assuming the cause is the same as https://github.com/graphprotocol/mission-control-indexer/issues/66.

grassets commented 4 years ago

Can this be due to parallelAllocations ?

crypt1d commented 4 years ago

Can this be due to parallelAllocations ?

could be! not sure how that works.

crypt1d commented 4 years ago

after testing with another graph id, it does seem to be related to parallelAllocations. It still seems strange to display these as separate in the UI, but not in the graph console.

I'd love to understand what that parameter even does!

rosewood5 commented 4 years ago

I may have seen the allocationAmount taken 3 times based on what happened here. Does that still fit with it being related to parallelAllocations?

trader-payne commented 4 years ago

parallelAllocations it's related to the number of state channels that are opened per deployment. I doubt that has anything to do with the issue you're having.

davekaj commented 4 years ago

Looks to me like the numbers are displaying correctly, but it might be a bit misleading. In the explorer - the amount allocated is the sum of all parallel allocations. In this case 2(50+100) = 300

We are working on adding tables to the UI that display allocation specific information on your own profile. Once we get the UI to the indexers with more detailed data, we can then revisit this issue and determine if we are still displaying data that is not clear / confusing

trader-payne commented 4 years ago

Jannis explained in detail over on Discord how parallelAllocations work and why the explorer sees multiple times the amount of GRT allocated. I'll post his message below.

From Jannis:

Some of you have reported that, even though you set an allocation amount of N in your rules, 2 * N GRT were allocated towards subgraphs (see https://github.com/graphprotocol/mission-control-indexer/issues/107). 
This is expected, but perhaps confusing. The allocationAmount is applied per allocation and by default, we use parallelAllocations = 2. 
So if you index 11 subgraphs, 22 allocations would be created (using 22 Ethereum transactions), each for allocationAmount GRT.

An alternative would be to use allocationAmount as the total and use allocationAmount / parallelAllocations for each allocation. 
Would that be less confusing? 
Consider that this is only consistent if you never change allocationAmount or parallelAllocations. 
If any of the two change (e.g. both increased by 1), only future/new allocations will use the new values, and existing allocations will use the old until they are closed.

Message link: https://discordapp.com/channels/438038660412342282/737341252835737641/760045365461909514

fordN commented 4 years ago

This is expected behavior, but improvements can be made to better document this behavior. I've made an issue to track this enhancement.