Konrad Garus added a comment - 19/Sep/2018 3:29 PM I found the issue in JSD codebase. Using sources decompiled by Intellij IDEA, but it gives you the idea. Let's say there are 70 requests for the user, and I'm running a query with start=50. That means there should be 20 requests on the page. Now, see comments in code below. ServiceDeskCustomerRequestServiceImpl : public Either<AnError, PagedResponse<CustomerRequest>> getCustomerRequests(@Nullable ApplicationUser user, @Nonnull CustomerRequestQuery customerRequestQuery) { Assertions.notNull( "customerRequestQuery" , customerRequestQuery); return Steps.begin( this .userFactory.wrap(user)).then((cu) -> { return this .dispatchCustomerRequestQuery(cu.forJIRA(), customerRequestQuery); }).yield((cu, customerRequests) -> { return customerRequests; }).map((input) -> { // At this point input is a list of 20 CustomRequests return PagedResponseImpl.toPagedResponse(customerRequestQuery.pagedRequest(), input); }); } PagedResponseImpl : public static <T> PagedResponse<T> toPagedResponse(LimitedPagedRequest limitedPagedRequest, List<T> items) { // items has 20 entries, limitedPageRequest.start=50 return filteredPageResponse(limitedPagedRequest, items, Predicates.alwaysTrue()); } public static <T> PagedResponse<T> filteredPageResponse(LimitedPagedRequest limitedPagedRequest, List<T> items, Predicate<? super T> predicate) { if (predicate == null ) { predicate = Predicates.alwaysTrue(); } boolean hasMore = items.size() > limitedPagedRequest.getStart() + limitedPagedRequest.getLimit(); // This takes the iterable of 20 items and skips 50, so the result is empty. BAM! List<T> filteredItems = FluentIterable.from(items).skip(limitedPagedRequest.getStart()) .limit(limitedPagedRequest.getLimit()).filter(predicate).toList(); return from(filteredItems, hasMore).pageRequest(limitedPagedRequest).build(); } One way to fix this to replace the call in getCustomerRequests : // From: return PagedResponseImpl.toPagedResponse(customerRequestQuery.pagedRequest(), input); // To: LimitedPagedRequest pagedRequest = customerRequestQuery.pagedRequest(); boolean hasMore = input.size() > pagedRequest.getStart() + pagedRequest.getLimit(); return PagedResponseImpl.from(input, hasMore).pageRequest(pagedRequest).build();

Konrad Garus added a comment - 19/Sep/2018 12:07 PM This is a disastrous show-stopper, not a low-priority bug that deserves no attentions for years. Since the assignee is showing as inactive, does it mean it will take 2 more years for someon to notice it again?

Andrew Sharpe added a comment - 16/Oct/2017 10:00 PM - edited WORKAROUND: It appears that the start parameter is affected by a factor of 2.  Using all the examples in this thread, if you imagine applying a start value that is double what was requested, the responses line up.  This has worked out OK in my testing so far, though it should be considered a workaround at best. It's possible there are interactions with the other parameters that might affect this, YMMV.  See also  https://jira.atlassian.com/browse/JSDSERVER-397

Andrew Sharpe added a comment - 12/Oct/2017 10:44 AM This was reported just over 2 years ago, and the API is no longer listed as experimental.  This issue also makes the API useless for anything other than the first page of results, and has more than "minor" severity for those wishing to use it.

Rechie Sanchez added a comment - 10/Mar/2017 7:36 AM I'm having the same issue about the results fetch. start parameter is not offsetting the result correctly. I have 13 issues on my list, when I tried to get limit=3&start=0 it returns (1-3) items which is correct. But when I query the next list which is limit=3&start=3, it returns (7-9) items which is wrong.   Hope it will be fixed sooner.