Is there an existing issue for this?
Current (incorrect 🙈) Behavior
Currently, it checks the stake key registration until the stability window of the current epoch. I think it should check till the beginning of the current epoch.
We had similar code in Yaci Store, which caused a mismatch in the adapot calculation for epoch 884 on the Preview network. This issue has already been fixed in Yaci Store.
In epoch 884, 15 pools retired, and the reward accounts for 10 retired pools were registered and deregistered in epoch 884.
|
HashSet<String> registeredAccountsUntilNow = dbSyncDataProvider.getRegisteredAccountsUntilNow(epoch, poolRewardAddresses, stabilityWindow); |
Expected Behavior (what you should have seen 🎉)
10 pool refunds should go to treasury.
Steps To Reproduce
Run adapot calculation of Preview epoch 884.
Environment
Anything else?
No response
Is there an existing issue for this?
Current (incorrect 🙈) Behavior
Currently, it checks the stake key registration until the stability window of the current epoch. I think it should check till the beginning of the current epoch.
We had similar code in Yaci Store, which caused a mismatch in the adapot calculation for epoch 884 on the Preview network. This issue has already been fixed in Yaci Store.
In epoch 884, 15 pools retired, and the reward accounts for 10 retired pools were registered and deregistered in epoch 884.
cf-java-rewards-calculation/validation/src/main/java/org/cardanofoundation/rewards/validation/data/fetcher/DbSyncDataFetcher.java
Line 118 in b05eddf
Expected Behavior (what you should have seen 🎉)
10 pool refunds should go to treasury.
Steps To Reproduce
Run adapot calculation of Preview epoch 884.
Environment
Anything else?
No response