Open nicolasochem opened 1 year ago
An update on this.
When running in retry mode, for every delegator with a failed payout, we update the balance:
but the only other occurence of update_current_balances()
function in the producer logic is in CalculatePhase4
which is for founders/owners.
We are not actually querying individual delegators balances with tzkt API during initial payment: we are bulk querying the indexer with a balance list of delegators self.reward_provider_model.delegator_balance_dict
.
Only during retries, we do it, which takes a very long time and often fails.
A solution would be to modify the retry logic to query all balances again using the same API as initial payment. I'm not going to do this now, instead I'll just record my observations here.
This is what's in the verbose log when this happens:
2024-02-15 17:46:15,839 - producer - DEBUG - Requesting https://api.tzkt.io/v1/accounts/tz2xxxxx
2024-02-15 17:46:15,950 - producer - DEBUG - Response from TzKT is:
{'activeRefutationGamesCount': 0,
'activeTicketsCount': 0,
'activeTokensCount': 60,
This was described on slack and I've seen it as well:
When TRD fails, the next run attempts to run the failed payments again. But this results in a lot of calls to tzkt api. Recently, it seems that this endpoint has been rate-limited, causing failure like the example below (taken on ghostnet TRD).
A workaround is to delete the failed payment folder (assuming it's a solid failure and not a partial payment). But it would be good to look into why it's querying every
Link to baker slack discussion: https://tezos-baking.slack.com/archives/CQ35AM8KE/p1685978794781209