Client reaches the allowed per minute update limit for a workitem.
But... for these daily ones...
Client reaches daily limit of workitem creations for organization.
Client reaches daily limit of workitem updates for organization.
Many applications have the 429 handling logic configured to retry using the retry-after header. That is even the default behavior of some of the SDKs... Couldn't this be a problem? What is the retry-after value for these cases?
If it is too high (like, until the next day), then the apps could freeze waiting for too long. But if it is short, then it would be retrying pointlessly.
Blockquote Many applications have the 429 handling logic configured to retry using the retry-after header. That is even the default behavior of some of the SDKs... Couldn't this be a problem? What is the retry-after value for these cases?
In daily limit breaches, we return the exact seconds left after which the limit will be offset.
If a user tries to create a workitem at 11:55 PM and the daily limit exceeds, the value of retry-after will be set to 300.
If a user tries to create a workitem at morning 11:55 AM and the daily limit exceeds, the value of retry-after will be set to 43500.
We discussed this internally and decided to go with 429 as if the user tries after some time the request will be successful.
Please let me know if this answers your questions.
Hello Saurav. Yes, that answers my question. I suppose the risk depends on how the retry logic is implemented. For example, digging up the Python and Go SDKs' code (the ones I use the most), it looks like there is a maximum for the time waiting when retrying. I suppose in the other ones you have considered it too. Thank you!