Bug: Incorrect Allocated GRT numbers in Explorer UI

[crypt1d]

Allocated GRT numbers are 2x bigger than in reality:

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]

Can this be due to parallelAllocations ?

[crypt1d]

Can this be due to parallelAllocations ?

could be! not sure how that works.

[crypt1d]

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]

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]

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]

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]

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]

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