nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Why is isLastPage false but no nextPageStart?

Curt Patrick

I am using the following url:

https://stash.corp.netflix.com/rest/api/1.0/projects/ENGTOOLS/repos/odin/commits/?since=8992ee6b49a941c5a08b4a1ec085444bf28e6e7a&until=e42d17ff3ee5d2f3fdb9bfb44fe2df878a1170e8&limit=4

Without the limit this query would return 15 values (and isLastPage equals true). With limit=4 I get four values and:

"size": 4,"limit": 4,"isLastPage": false,"start": 0

Notice that isLastPage is false, but no nextPageStart is provided. The documentation says, "If more than one page exists (i.e. the response contains "isLastPage": false), the response object will also contain a nextPageStart attribute", so why am I not getting a nextPageStart value?

BTW, I did some further experimenting: I get the nextPageStart value if I remove the 'since' parameter. That narrows down the problem, but I don't see any work around since I really do need to define a starting point and an ending point for the commits.

Accepted answers

jhinch (Atlassian)

Hi,

This is a bug in the Stash REST API due to an alternate paging implementation being used which doesn't expose the nextPageStart attribute. You can still build the next page request programatically based off the other information given in the response.

I've raised a bug to track the progress of fixing this inconsistency:

https://jira.atlassian.com/browse/STASH-3253

All comments

jhinch (Atlassian)

Hi,

I've raised a bug to track the progress of fixing this inconsistency:

https://jira.atlassian.com/browse/STASH-3253

Curt Patrick

Thanks for the explanation.

As for building the next page programatically, the doc says:

Identifiers of adjacent objects in a page may not be contiguous, so the start of the next page is not necessarily the start of the last page plus the last page's size. A client should always use nextPageStart to avoid unexpected results from a paged API.

If that is true, I don't see how I can reliably build the the next page call?

jhinch (Atlassian)

This can be true for resources which provide filtering capabilities (such as filtering users by matching usernames). It is fine to do for the commits resource as a workaround for the bug raised

Curt Patrick

In that case, it will work for me. Thx.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

bitbucket-server