EPIC: Improve throttling mechanism with retries #713
Labels
admin: epic
An EPIC -- meta issue used to track a body of work
admin: key-result
A key result (in the context of OKRs)
S: NewThings
Work towards your business objectives with new products, features, or integrations
type: feature-request
New feature or request improvement
Problem
Currently the throttling mechanism is designed so that provider logic (slash meter, etc.) dictates how many slash packets can be handled over time. Throttled slash packets are persisted on the provider, leading to issues such as #594. We can improve the throttling mechanism to instead queue/persist relevant data on each consumer, and have consumers retry slash requests as needed. CC @jtremback who came up with this idea
Closing criteria
Relevant data is persisted on each consumer with retry system implemented to enforce throttling.
Problem details
Task list
Must have
Nice to have
The text was updated successfully, but these errors were encountered: