Nsryjdtyk

We have an application that uses the Gmail API to access emails in Gmail.

Randomly we got the following error message

Google.Apis.Requests.RequestError Rate Limit Exceeded [429] Errors [
Message[Rate Limit Exceeded] Location[ - ] Reason[rateLimitExceeded]
Domain[usageLimits] ]

Which we then retry in our code on error event and got

Google.Apis.Requests.RequestError Backend Error [500] Errors [
Message[Backend Error] Location[ - ] Reason[backendError]
Domain[global] ]

which we then retry in our code on error event (we try 3 times) and it worked as expected.

There is some issue with the Gmail API backend here. we are making < 1000 Gmail API calls per day and nothing concurrent so I can't see that we have breached any limits.

Anybody else encountering this strange behaviour?

Here is the code that is being called

 UsersResource.MessagesResource.GetRequest gr = gs.Users.Messages.Get(emailAccount, msgId);

 {

        gr.Format = UsersResource.MessagesResource.GetRequest.FormatEnum.Raw;

        Message m = new Message();

        try

        {

            m = gr.Execute();

        }

 }

The Gmail API has the same daily usage limit that applies to all requests made from your application, as well as per-user rate limits.

• Daily Usage 1,000,000,000 quota units per day Per User Rate
  Limit


• 250 quota units per user per second, moving average (allows
  short bursts)

Exceeding a rate limit (going to fast) will cause an HTTP 403 or HTTP 429 Too Many Requests response and your app should respond by retrying with exponential backoff.

The 500 errors are server hiccups the server took to long to respond so it timed out your request. The solution for this is the same as the solution for the above error you should implement exponential backoff and try again.

Exponential backoff is a standard error handling strategy for network
applications in which the client periodically retries a failed request
over an increasing amount of time. If a high volume of requests or
heavy network traffic causes the server to return errors, exponential
backoff may be a good strategy for handling those errors. Conversely,
it is not a relevant strategy for dealing with errors unrelated to
rate-limiting, network volume or response times, such as invalid
authorization credentials or file not found errors.

Used properly, exponential backoff increases the efficiency of
bandwidth usage, reduces the number of requests required to get a
successful response, and maximizes the throughput of requests in
concurrent environments.

The flow for implementing simple exponential backoff is as follows.

1. Make a request to the API


2. Receive an error response that has a retry-able error code


3. Wait 1s + random_number_milliseconds seconds


4. Retry request


5. Receive an error response that has a retry-able error code


6. Wait 2s + random_number_milliseconds seconds


7. Retry request


8. Receive an error response that has a retry-able error code


9. Wait 4s + random_number_milliseconds seconds


10. Retry request


11. Receive an error response that has a retry-able error code


12. Wait 8s + random_number_milliseconds seconds


13. Retry request


14. Receive an error response that has a retry-able error code


15. Wait 16s + random_number_milliseconds seconds


16. Retry request


17. If you still get an error, stop and log the error.