Pagination inconsistency in fetching page/blogpost versions

Issue Summary

Customers are experiencing inconsistent results fetching page versions when performing pagination using the API v2. In addition the paginated result set is ending prematurely without returning all the results.

Steps to Reproduce

Fetch page versions for a page with over 50 versions

1. Use /api/v2/pages/<page-id>?include-versions=true to fetch initial page

2. Use /api/v2/pages/1594262043/versions?cursor=<cursor>

3. Repeat 2. till we have no more entries returned

Expected Results

We should get results (in batches of limit or default of 25) in descending order of version createdAt date (i.e. most recent to least recent).

Actual Results

Only the first set of paginated results is in descending order of version createdAt date. Subsequent paginated results are in ascending order of version createdAt date (i.e. least recent to most recent). As a result we may no longer fetch all the versions.

As an example for a page with 448 versions, here’s what we see:

/api/v2/pages/<page-id>?include-versions=true -> 448-399 (descending)
/api/v2/pages/<page-id>/versions?cursor=<cursor> -> 398-374 (ascending) /api/v2/pages/<page-id>/versions?cursor=<cursor> -> 375-399 (ascending)  /api/v2/pages/<page-id>/versions?cursor=<cursor> -> 400-424 (ascending)  /api/v2/pages/<page-id>/versions?cursor=<cursor> -> 424-448 (ascending)  No more results

Workaround

Manually append &sort=-modified-date to fetch all results in descending order of modified date.