| Issue 1772: | Truncated replies to large /changes/ queries set "_more_changes: True" in expected ways | |
| 2 people starred this issue and may be notified of changes. | Back to list |
Affected Version: 2.5.1 What steps will reproduce the problem? 1. Issue a large (that would return more than 500 results) /changes/?q=... query (Accept: application/json) and store the result 2. Issue the same query but add &n=500 and store the result 3. Issue the same query but add &n=501 and store the result What is the expected output? What do you see instead? I would expect that every time the number of changes to return has been truncated (either because of hitting the user provided "n" limit or because of hitting an internal Gerrit limit), the last change would have a "more_changes: True" field set. What actually happens is unexpected: - if no "n" has been provided then you never get "_more_changes: True" (not even when the result is truncated after returning 501 changes) - if "n" is provided and it's <=500 then you get <="n" changes and the last change has "_more_changes: True" set if there are more changes to return - if "n" is provided and is set to >500 then you get 501 changes and no "_more_changes: True" is set Please provide any additional information below. The problem with this behavior (besides being not what one would expect) is that it makes code issuing large queries error prone. In order to make such code work well it would have to always provide n=500 but if the Gerrit server changes that internal limit in the future then: - if it's lowered the user code breaks silently, as it will return the <internal-limit>+1 changes and no _more_changes: True is set at the end, it will think that there are no more changes to resume the query for - if it's increased then the user code is suboptimal because it will split large replies by "500" instead of the (now) larger internal limit So my suggestion is to change the behavior as follows: if a large reply was truncated (either because of user supplied "n" or because of Gerrit internal limit) then the last change in the reply should ALWAYS have "_more_changes: True" set
Jan 25, 2013
Project Member
#1
edwin.ke...@gmail.com
Status:
ChangeUnderReview
Jan 26, 2013
(No comment was entered for this change.)
Status:
Submitted
Labels: FixedIn-2.6
Jan 29, 2013
Is this fix supposed to make Gerrit add "_more_changes: True" to the last change in all cases where the output is truncated? Because it doesn't seem to be doing so if issuing a query like this: /changes/?q=status:merged (where it would return more than 500 changes or whatever the internal limit is set to be). Was such a case tested? Thanks!
Jan 29, 2013
(No comment was entered for this change.)
Status:
Accepted
Owner: sop@google.com |
|
| ► Sign in to add a comment |