-
Notifications
You must be signed in to change notification settings - Fork 5
update too many req cooldown handling #176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: dev
Are you sure you want to change the base?
Conversation
| public static final String FITBIT_COOLDOWN_STRATEGY_CONFIG = "fitbit.cooldown.strategy"; | ||
| private static final String FITBIT_COOLDOWN_STRATEGY_DOC = "Strategy for handling too many requests cooldown. Options: ROLLING_WINDOW, TOP_OF_HOUR"; | ||
| private static final String FITBIT_COOLDOWN_STRATEGY_DISPLAY = "Cooldown strategy"; | ||
| private static final String FITBIT_COOLDOWN_STRATEGY_DEFAULT = "ROLLING_WINDOW"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that the TOP_OF_HOUR approach should be the default, right. It conforms to the cooldown strategy of Fitbit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but this is to keep the default behaviour (to not affect existing deployments if they have no notion of this new feature).
|
|
||
| public Duration getTooManyRequestsCooldownInterval() { | ||
| return Duration.ofHours(1); | ||
| return Duration.ofSeconds(getInt(FITBIT_TOO_MANY_REQUESTS_COOLDOWN_CONFIG)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here we have an issue of problems with backwards compatibility I think. We should take care to add some migration note to RADAR-Kubernetes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean? The default is set to 1hr still so should not change any functionality in existing deployments.
mpgxvii
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
According to this, the rate limit is reset at the top of the hour, unlike the current implementation - using a rolling window from when the error is received.
This PR adds a strategy to calculate cooldown/backoff time based on top of the current hour. But the legacy code is till present and is the default. Configuration can be dones as follows-
This PR also makes the backoff configurable. This was hardcoded to 1hr by default. Though i think we don't need to update this dynamically since rate limit is by the hour (150 req per hour), but would be good for testing and debugging.