BUG - spo-stake-distribution #1316
Description
While comparing some governance proposal numbers from DBSync with output from cardano-cli (10.13.1.0), it mostly matches down to the lovelace for all the different buckets I sum up for DRep and SPOs.
However, for the SPO tally, I noticed something strange regarding the always abstain status.
1.
Querying the cli query spo-stake-distribution I can see that pool with hash d68eed68381b65beb04fc7984dfa156c4dbf53c7911e900af6a535ef has the following data:
["d68eed68381b65beb04fc7984dfa156c4dbf53c7911e900af6a535ef",339284886531,null]
Ie it still has active stake according to the output, but is not marked as vote-delegated to always abstain.
It is set to expire in 601 (current epoch).
Its reward stake key is vote-delegated to Abstain and hasn't been deregistered or delegated to another DRep.
Most explorers have already marked the pool as retired.
Is the pool considered retired already, or is it first after the end of the current epoch?
DBSync also still has an entry for the pool in its pool_stat table for the current epoch.
Is the retiring epoch inclusive or exclusive?
If the stake is still active until the end of the epoch, shouldn't it then also still be marked as being vote-delegated to always abstain?
2.
Pool with hash 982f926165ebf6699df8704a16d11c9e13c88c4e02f63e3fe5af7181 has a pool update with a new reward address in epoch 599 set to go active in 602 (next epoch). The old rewards address was vote-delegated to CF, while the new one (for the update yet to take effect) is vote-delegated to Abstain.
Yet, in query spo-stake-distribution, it's listed as vote-delegated to always abstain, even though the update is not yet active.