After authentication i simply call the following again and again until I am rate limited:
BusinessUnitListing businessUnitListing = WorkforceManagementApi.getWorkforcemanagementBusinessunitsDivisionviews(divIDs);
I had the retry configuration enabled with both setMaxRetryTimeSec and setRetryMax but the code does not handle rate limiting at all. Exception is thrown with Retry-After HTTP header but the code does not wait at all nor it tries again. I expected that that SDK will wait automaticall "Retry-After" seconds and retry if there is still time left from the max retry timer.
The questions I had:
I can manually add delay processing the Retry-After header but isn't it supposed to be automatic with Java SDK?
Isn't the code supposed to retry the request if there is still time if setRetryMax is set to > 1?
i can see that sometimes the Retry-After header is set to 0 which doesnt make sense. I need to use a manual low number in this case (few seconds)
I wanted to query to http response code to validate if it is 429 but i couldn't find it anyhwere. I checked the exception getstatuscode() but it only gives me 400 which is not very specific. getStatusReasonPhrase() returns only "error" so not helpful.
I feel I am missing something painfully trivial...
I see you're using the logging configuration when building the ApiClient. Have you been able to log the error response? If the response status code is a 429 then it's a bug in the SDK and our team will look into it.
If it's a 400 status code then that is more than likely a bug with that particular endpoint because they should be returning a 429 in that case.
I've tested this using the same retry configuration and it seems to be working just fine.
If you get a 400 status code after being rate limited please create a ticket with our customer care team and they will investigate the issue with the API.
Hi Ronan, i turned on the loggin with trace level and I can see HTTP 400 is returned but it has proper Retry-After header
=== RESPONSE ===
Status: 400
Headers:
Strict-Transport-Security: max-age=7776000
Retry-After: 2
Connection: keep-alive
...
Actually I worry less about getting 400 vs 429 but I was expected the SDK to retry automatically and also wait "retry-after" seconds automatically but neither happens automatically. I can parse the Retry-after header and wait automatically but then what's the point in the retry configuration?
Or maybe the retry logic fails to kick in because cloud sends HTTP 400 and not 429? Did you code both automatically retry and wait when rate limit was hit?
Or maybe the retry logic fails to kick in because cloud sends HTTP 400 and not 429
That's exactly what's happening. The retry logic in the SDK only retries 429 codes.
This is a bug with the API - They should be sending a 429 code in this case. I would strongly recommend reporting this issue to Care so the bug can be resolved. In the meantime feel free to implement retries for 400 status codes on this endpoint until the bug is fixed. We don't plan on adding retry logic for 400 codes because this is non-standard behaviour.
Just to confirm the solution: the 400 response came from the authentication service, not the actual workforce management API. The engineer confirmed that 400 is used to be fully compliant with the OAuth2 specification. I guess this is just something to keep in mind but this should not be a problem in general because we usually authenticate once and call the API many times.