2662: Repository List Resource web service API doesn't return all repos

eyu****@gmai***** (Google Code) (Is this you? Claim this profile.)
david
 david
Aug. 12, 2013 
What version are you running?
1.6.1

What's the URL of the page containing the problem?
/api/repositories/?start=0&max-results=233

What steps will reproduce the problem?
I have 233 repos in total. Per http://www.reviewboard.org/docs/manual/dev/webapi/2.0/resources/repository-list/, I should get all repos back if I pass in query string max-results, however, it seems the maximum number of repos returned is always 200.  

So I'm not able to get the 201th repo in the returned json

To verify the issue, I changed the query string start from 0 to 35. After incrementing the starting index, I can get the 201th repo in the result. 


What operating system are you using?
Centos 6


Please provide any additional information below.
It is true that I can get away with this by incrementing the start, but I'm just wondering if you use paginator to implement this feature? and the maximum per page is 200? 

If that is the case and you guys don't plan to fix it, please update the API documentation as that limit is not clearly stated.
chipx86
#1 chipx86 
Definitely sounds like a bug. I'm a bit surprised by that.
  • +Confirmed
  • -Priority-Medium
    +Priority-High
    +Milestone-Release1.6.x
    +Component-API
  • +chipx86
#2 raja****@gmai***** (Google Code) (Is this you? Claim this profile.) 
This seems to be a limit set in djblets/webapi/core.py:WebAPIResponsePaginated. Although the "links" array should point to the next page in case the total results is greater than what is requested, I agree with OP that if its requested, it should return all the records.

Can this line:

max_results = \
                min(int(request.GET.get('max-results', default_max_results)),
                    max_results_cap)

be changed to
try:
    max_results = int(request.GET.get('max-results'))
except ValueError:
    max_results = default_max_results

We could remove the "max_results_cap" variable as well with the above change. From a performance standpoint, it could be an issue if we have lots of results obtained through the API. 

Since the original design does provide a "next" url for pagination, that seems a decent solution as long as its documented.
david
#3 david 
I don't think getting rid of the cap is really a good idea, since it opens us up to DoS issues. We can do a better job of documenting this, though.
  • -Confirmed
    +Started
  • -Milestone-Release1.6.x
    +Milestone-Release1.7.x
    +Component-Docs
  • -chipx86
    +david
david
#4 david 
Doc fix pushed to djblets master (696bc56). Thanks!
  • -Started
    +Fixed