Overlap in paging of descendants API

We are providing an app that does recursive updates on page titles within a page hierarchy. To do that, we run the following sequence:

  1. Fetch the root page of the hierarchy using /rest/api/content/{id}?expand=descendants.page.
  2. The descendants.page expansion contains a maximum number of 25 results. In case there are more descendants (which is indicated by the presence of a next link), we fetch further pages by using /rest/api/content/{id}/descendant/page?start=25&limit=200.
  3. We iterate over the page and its descendants and update its title using PUT /rest/api/content/{id}.

A customer has reported a crash of our app. Upon investigation, I found out that it is caused by a page appearing twice in the list of pages, as the 25th and 26th page. Because we are sending a { version: { number: page.version.number + 1 } }, the second call fails because the version number is now wrong.

The fact that this page is the 25th and 26th one indicates that it is returned as the last descendant in the expansion of its root page, but then again as the first descendant in the request to the descendant API. This indicates that there is something wrong with the paging.

I could easily build a workaround by simply filtering out duplicates. But I’m worried that the underlying problem might be that the order of the pages changes in between the two requests, which might cause pages to be missing.

The problem is that I cannot reproduce the issue on my instance. It seems to be only happening in one particular space of the customer. Even in another space on the same instance it doesn’t occur.

A very similar issue had been reported here but has been marked as “Fixed” without further comment. There is also a discussion in a Google Group that describes similar behaviour.

Since I cannot reproduce the issue to investigate it further, I’m wondering if anyone has experienced before, and which way you chose to deal with it.

@candid I, too, am unable to reproduce. Can you please file a DEVHELP ticket and provide details, including instance info and debug info? (API calls, payloads, etc.) Once we have that info, we can escalate to the Confluence team.