Handling for Rate Limiter errors - `Too many requests`

[santhoshramaraj]

SystemLink Enterprise's services implement rate limiters to limit the client's requests per second. Whenever a client crosses the rate limiter, the client experiences Too many requests error. Currently, the clients do not have any support for a back-off-retry mechanism to simplify the usage.

[santhoshramaraj]

FileClient incorporates a basic rate limiter handler described in #65

[santhoshramaraj]

DataFrameClient incorporates a basic rate limiter handler described in #80

[ChrisStrykesAgain]

Maybe I'm missing something obvious, but is there a reason to implement this on a per-service level, instead of just putting it in the base class?

[santhoshramaraj]

Per-service level implementation was a temporary solution to get the integration tests working.

#90 aims to enable users to choose and handle the retry for common use cases. Implementing it in the BaseClient is also a solution and exposes them through each Client arg.

[ChrisStrykesAgain]

I think many consumers of the API won't be thinking about retry handling, so even if we expose methods and tools to enable it they may not use them. Also, I think the situation where a user specifically wants to not retry (especially on 429s) is by far less common. Given these two things, I think building this into the base class as the default behavior (with the capability to disable) would be an ideal scenario and make more users successful. I'm happy to do said implementation if others are onboard with the idea.

[santhoshramaraj]

That is a valid point, I am good with implementing a default retry behavior in BaseClient and allowing the user to override or disable as needed.

[santhoshramaraj]

Most clients have implemented a standard handling for common errors.