-
Bug
-
Resolution: Timed out
-
Low
-
Severity 3 - Minor
-
Issue Summary
Start parameter isn't working when using the GET /wiki/rest/api/content/{id}/child/{type} API with Custom Types.
Steps to Reproduce
- Create a new cloud app that introduces its own custom content type
- Create two custom content items as children of a page
- Request those custom content items through the content child API. Set the start query parameter to 0 and the limit query parameter to 1: GET /content/<id>/child/<custom-content-type>/?start=0&limit=1
- Do the same request again, this time set start to 1: GET /content/<id>/child/<custom-content-type>/?start=1&limit=1
- Do the same request again, this time set start to 2: GET /content/<id>/child/<custom-content-type>/?start=2&limit=1
Expected Results
Get two different responses from items 4 and 5.
Actual Results
The start parameter is ignored and we receive the same response from items 4 and 5.
Workaround
Currently, there is no known workaround for this behavior. A workaround will be added here when available.
Hi Matthew
We have some limitations in our app - Scroll Documents for Confluence, because of this bug. It concerns the number of read requests or confirmations that we can support (both in the migration and during normal operation).
Is there any chance this bug can be fixed, or at least, a workaround can be shared?
Thanks!