-
Notifications
You must be signed in to change notification settings - Fork 18
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
add TooManyRequestError to sfxclient #179
Conversation
return t.Sub(time.Now()), nil | ||
} | ||
|
||
// Retry-After: <delay-seconds> |
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.
It looks like this form is the only one we emit, not the (above, and likely correct) HTTP 1.1 date.
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.
(just a note, that you included the date parse above is nice of you!)
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 like it. Adding the new error type seems appropriate as we're returning additional headers.
This patch will allow the client to discern a 429, but it does not adjust the behavior of the sink to honor the |
@cory-signalfx thanks for the quick review 😄 unfortunately it breaks the build:
I'll read the build script and make sure it's green before submitting another PR to fix that. |
Some information from SignalFx could be used to help the client to decide what to do on failure:
429 is only returned by the ingestion data points when a limit has been reached of metrics or event rates.
There is a Throttle-Type header returned with the 429 which indicates what the reason was for the 429 to be returned.
There is a Retry-After header returned with the 429 which indicates the backoff time which should be used.