Confluence REST API reports parent ID - but parent page doesn't exist. Known behavior?

This issue is probably related (again) to pages migrated from on-prem to the cloud.

I’ve got a page that has a missing parent. What I mean is that the REST v2 API returns a parent ID - but there is no page with that ID.

Specifically when calling the v2 endpoint /wiki/api/v2/pages/2222222222 I get a result like this:

{
  "id": "2222222222",
  "parentId": "1111111111",
  "parentType": "page",
  "position": null,
  "title": "Page Title"
}

Note the parentId is being set to 1111111111. Yet, retrieving a page with that ID yields a 404 response.

When calling the v1 endpoint /wiki/rest/api/content/2222222222?expand=ancestors I get this instead:

{
  "id": "2434331554",
  "type": "page",
  "title": "Page Title",
  "ancestors": [],
  "extensions": {
    "position": "none"
  }
}

Note the empty ancestors array.

When opening page 2222222222 in the browser, the page tree places the page below the root page of the space (this root page has a different ID than the reported parentId). The page also looks oddly out of place at a top-most position (judging by its real title). Also, no other pages are shown in the tree when having it open (except children of our odd page) - although there are dozens when opening a different page.

What’s going on here? Is this a known and expected phenomenon, maybe with migrated pages, if the parent page hasn’t been properly migrated?

At least this shall be a heads-up to everyone to expect this situation in Confluence Cloud.

1 Like

Thanks for reporting. I have the feeling that the API v2 is not yet working 100%.

2 Likes

My gut feeling is that the parent page got missing during a migration, the reference is still there in the database, and the API endpoints handle this differently. Not sure what’s the right thing to do here from an API implementation standpoint. REST v2 is more honest than v1 which claims that there is no parent (which would make the page a root page).

So, v2 probably not to blame in this case but I agree that it needs more time do grow properly. There are too many other issues open atm.

If you have an object that exists but you do not have permission to access it, the REST API V.1 will return HTTP 403, but the REST API V.2 will return HTTP 404 instead.

So is it that the page does not exist, or just that you do not have access to it? In the general case, you can never know. (That is probably not the case here though, because I think that access to the child page implies at least view access to all parents.)

However, this is an unfortunate design decision when considering content updates. You might fetch a piece of content successfully, but when you try to PUT it (using the exact same URL), you may then get a HTTP 404. This actually means that you have read permission but not write permission.

I’m only trying to read basic page data via GET. I can GET the child. So I should be able to GET the parent, as you say. But the parent cannot be GETten ^^.