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
{{ message }}
This repository has been archived by the owner on Jan 21, 2022. It is now read-only.
With the current implementation of groupBy in abacus-batch event if there is is an error in a call in one of the groups, all groups response with that same error.
Imagine the following situation.
Two clients post their usage to the collector in parallel. The first one with valid usage and the second one with out of slack window. The requests are received in batch in the accumulator. It starts to groupReduce them and the second one which is not in the slack throws. This will result in reporting the same error to both clients, despite the fact the usage doc of the first client has been processed successfully. This could also happen for all kind of throw errors that are not handled in the dataflow reducers, not only for out of slack.
The text was updated successfully, but these errors were encountered:
With the current implementation of
groupBy
in abacus-batch event if there is is an error in a call in one of the groups, all groups response with that same error.Imagine the following situation.
Two clients post their usage to the collector in parallel. The first one with valid usage and the second one with out of slack window. The requests are received in batch in the accumulator. It starts to groupReduce them and the second one which is not in the slack throws. This will result in reporting the same error to both clients, despite the fact the usage doc of the first client has been processed successfully. This could also happen for all kind of throw errors that are not handled in the dataflow reducers, not only for out of slack.
The text was updated successfully, but these errors were encountered: