-
Bug
-
Resolution: Fixed
-
Low
-
8
-
Severity 3 - Minor
-
3
-
Issue Summary
When running the api call /rest/api/2/user/picker?query=<username> (or /rest/api/3/user/search) continuously, the api call at times will give a response with 200 OK but zero results. In the back-end, we see it is actually hitting 429 (rate limiting). Need to propagate 429 as a response for the api call too.
Steps to Reproduce
- Run /rest/api/2/user/picker?query=<username> (or /rest/api/3/user/search) multiple times.
- Most of the times it gives a result.
- At times it will give an empty list with 200 OK response – On checking the back-end we see it actually hitting the rate limiting with a 429 error code.
Expected Results
It should give a 429, as seen in the backend. This way the customers can understand that they are actually hitting the rate limit.
Actual Results
The below errors are found in the logs:
{"users":[],"total":0,"header":"Showing 0 of 0 matching users"}
CPUS returned unexpected status code: 429 for tenants XXXXXXXXXXXXX and principal XXXXXXXXXX
Workaround
No workaround.
This is more of a missing information that the customer's are not receiving and creating confusion.
- relates to
-
GORDIAN-931 Failed to load
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
Thank you for reporting your problem and apologise for the delay of change that may cause any inconvenience.
We have released the code change to propagate rate limit http 429 on the user search endpoints. That means you won't see http 200 empty response when your requests reach our rate limit, instead you will receive proper 429 http response.
Please feel free to reach us again if there is any any issue. Thank you for your patient!