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
Describe the bug
When a sender is denied, it aggregates too slow since rav requests are only triggered by UpdateReceiptFees message.
Those messages are only sent when the rav request finishes or after retry_interval (~30 secs).
This makes the aggregation process too slow in cases where the aggregator is UP. Our logic currently treats that the aggregator is down but what might have happened is that tap-agent was down for a while and now the sender is denied.
Solution
We should use the backoff_information to retry aggregating instead of a fixed retry_interval.
The text was updated successfully, but these errors were encountered:
Describe the bug
When a sender is denied, it aggregates too slow since rav requests are only triggered by
UpdateReceiptFees
message.Those messages are only sent when the rav request finishes or after
retry_interval
(~30 secs).This makes the aggregation process too slow in cases where the aggregator is UP. Our logic currently treats that the aggregator is down but what might have happened is that tap-agent was down for a while and now the sender is denied.
Solution
We should use the backoff_information to retry aggregating instead of a fixed retry_interval.
The text was updated successfully, but these errors were encountered: