You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The real rewards (e.g. from beaconcha.in) are 2309,4474,2408. So we are off-by-one in the target property. Most probably the situation is again that in the calculation of the target there is a big number in the numerator of a fraction (e.g. current epoch) and then the whole fraction is converted to int, so the bug only happens rarely.
What makes this situation much more sinister this time around, is that I don't see the error anymore, when I sat down to investigate, the current caplin reports are correct for this epoch.
My thinking regarding what's happening is this:
in caplin there are two calculation paths for these RPCs: one for recent epochs (finalized and close to finalized),
one for historical data,
my assumption is that I fixed with the PRs the historical, but not the recent data.
I have a system that continuously downloads these values to an sqlite DB, so I will know in the coming days if this issue is reoccurring and if it's always the case that the issue goes away once the epochs are antiquated. At that point, I will be able to unpatch my historical fixes and I will be able to conclude whether the buggy epochs are exactly the same between the two codepaths. If they are, then I can try to check how did my fix in #12076 doesn't apply to recent epochs, because at first look it does apply.
In the meantime, I will blog here any occurrences, so others can help out too.
Anyways, at least the issue is not critical anymore, because there is an easy fix once the epochs are antiquated: just delete them from my DB and refetch into the DB from the antiquated caplin, since then the reports are correct.
The text was updated successfully, but these errors were encountered:
Even with current patches from PR #12073 and PR #12076, I saw this today:
The real rewards (e.g. from beaconcha.in) are 2309,4474,2408. So we are off-by-one in the target property. Most probably the situation is again that in the calculation of the target there is a big number in the numerator of a fraction (e.g. current epoch) and then the whole fraction is converted to int, so the bug only happens rarely.
What makes this situation much more sinister this time around, is that I don't see the error anymore, when I sat down to investigate, the current caplin reports are correct for this epoch.
My thinking regarding what's happening is this:
I have a system that continuously downloads these values to an sqlite DB, so I will know in the coming days if this issue is reoccurring and if it's always the case that the issue goes away once the epochs are antiquated. At that point, I will be able to unpatch my historical fixes and I will be able to conclude whether the buggy epochs are exactly the same between the two codepaths. If they are, then I can try to check how did my fix in #12076 doesn't apply to recent epochs, because at first look it does apply.
In the meantime, I will blog here any occurrences, so others can help out too.
Anyways, at least the issue is not critical anymore, because there is an easy fix once the epochs are antiquated: just delete them from my DB and refetch into the DB from the antiquated caplin, since then the reports are correct.
The text was updated successfully, but these errors were encountered: