Microsoft-graph-docs: Provide an example of a 429 response from Graph for supported resources

Created on 28 Jan 2019  Â·  5Comments  Â·  Source: microsoftgraph/microsoft-graph-docs

Like the create contact documentation, it'd be helpful if an example of a 429 response was actually shown in the documentation.

Thanks,
Z


Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

azurAAD throttling fixed

Most helpful comment

Adding to this request. Graph seems to be returning invalid retry-after header values. Fiddler traces show I'm receiving 429 Too Many Requests error codes from batched requests sent to the v1.0/$batch endpoint, but the Retry-After header I'm receiving are all decimals (0.249, 0.124 etc). HTTP spec says positive integers or timestamps are valid, but I'm receiving a decimal. Not sure how to handle it so some documentation would be useful! I get an exception when calling

new HttpResponseMessage().Headers.Add("Retry-After","0.256");

but absolutely fine when I call

new HttpResponseMessage().Headers.Add("Retry-After","120");

as an example of a valid Retry-After header.

Batch Response

All 5 comments

Adding to this request. Graph seems to be returning invalid retry-after header values. Fiddler traces show I'm receiving 429 Too Many Requests error codes from batched requests sent to the v1.0/$batch endpoint, but the Retry-After header I'm receiving are all decimals (0.249, 0.124 etc). HTTP spec says positive integers or timestamps are valid, but I'm receiving a decimal. Not sure how to handle it so some documentation would be useful! I get an exception when calling

new HttpResponseMessage().Headers.Add("Retry-After","0.256");

but absolutely fine when I call

new HttpResponseMessage().Headers.Add("Retry-After","120");

as an example of a valid Retry-After header.

Batch Response

Adding to this request. Graph seems to be returning invalid retry-after header values. Fiddler traces show I'm receiving 429 Too Many Requests error codes from batched requests sent to the v1.0/$batch endpoint, but the Retry-After header I'm receiving are all decimals (0.249, 0.124 etc). HTTP spec says positive integers or timestamps are valid, but I'm receiving a decimal. Not sure how to handle it so some documentation would be useful! I get an exception when calling

new HttpResponseMessage().Headers.Add("Retry-After","0.256");

but absolutely fine when I call

new HttpResponseMessage().Headers.Add("Retry-After","120");

as an example of a valid Retry-After header.

Batch Response

So looking further in the spec, decimals are valid but standard HttpResponseMessage headers can't handle them when parsing Retry-After headers which is frustrating so may raise a bug over there. There really needs to be documentation around handing retry-after headers as part of batched calls. Should retry-after headers be honoured for just the individual batched request that received a 429 response, or should it be honoured for entire HTTP calls made against the $batch endpoint? In practise I've found doing the former I eventually start receiving 403 Unauthorized, but doing the latter it's all ok, but does slow things up a fair bit.

I use the 2.0 endpoint. Fiddler shows a corrent "Retry-After" misc. header (integer value).

Like the create contact documentation, it'd be helpful if an example of a 429 response was actually shown in the documentation.

Thanks,
Z

Document Details

⚠ _Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking._

Might be a bit late, but this is a sample output in case of failure of the batch request:

responses [
  {
    id: '1',
    status: 429,
    headers: { 'Retry-After': '1', 'Cache-Control': 'private' },
    body: { error: [Object] }
  },
  {
    'id': '2',
    'status': 400,
    'headers': { 'Cache-Control': 'private' },
    'body': {
      'error': {
        'code': 'BadRequest',
        'message': "Resource not found for the segment '...'.",
        'innerError': {
          'request-id': '79ea1884-300f-4a1b-a796-4eaa0c78ec6e',
          'date': '2020-04-13T14:00:52'
        }
      }
    }
  },
  {
    'id': '3',
    'status': 201,
    'headers': {
      'Location': "...",
      'Cache-Control': 'private',
      'OData-Version': '4.0',
      'Content-Type': 'application/json;odata.metadata=minimal;odata.streaming=true;IEEE754Compatible=false;charset=utf-8',
      'ETag': 'W/"wtrCk4zkjU6bIuSiBdYqegABZgKOUA=="'
    },
    'body': {...},
  }
]

Hey everyone.
Sorry about the delays it took to resolve this issue and thanks for your feedback.
Over the last few months we've added a lot of information to the throttling page. (mostly service limits)
I've just authored #9559 to address this issue, which will be closed whenever the PR gets merged.
Don't hesitate to provide feedback on the pull request.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

GregSpyra picture GregSpyra  Â·  4Comments

aaronrogers picture aaronrogers  Â·  3Comments

bijithbalan picture bijithbalan  Â·  4Comments

findyoucef picture findyoucef  Â·  4Comments

dcnoren picture dcnoren  Â·  4Comments