Hello,
I think there is a bug in the following REST API
→ wiki/rest/api/content/search?cql=id
We were using this URL → wiki/rest/api/content/search?cql=id in (90101010,9101010101) to get the content of multiple pages.
We noticed that on some pages and especially for NEWLY created pages, this api STOPPED giving us back the result.
As a workaround, we tested the new REST API V2 wiki/api/v2/pages?id=90101010,9101010101 and it works fine.
Is there any explanation for that?
Best,
Mixalis
+1, we’re seeing the same behaviour on that endpoint when searching by CQL
Hi @VakalosMixalis and @barbora,
Upon checking, there are no changes announced mentioned in the changelogs. In order to progress the investigation of this case, kindly raise a bug report in this portal.
Cheers,
Ian
Hello,
I experienced the same problem but the solution you’re suggesting isn’t working on the server edition of Confluence.
Are you aware if it’s possible to run v2 on server?
Best,
Vassia
Welcome to the Atlassian developer community @VassiaBravou,
No. This thread does not apply to Server/Data Center. I would recommend starting a new topic since the symptom might be the same but the underlying problem will be different.
Hi Team,
Is there an update on this issue ?
I am facing the same problem with this API endpoint for these parameters :
cql=lastmodified > 2024-01-12&expand=history.lastUpdated
From what I can tell, you have a new problem. @VakalosMixalis’s report to support did not result in a bug, just a resolution as “fixed”. I would encourage you to follow that path. Can you open a ticket with developer support?
Hi, is there any update on this issue? We’re still experiencing the same problem.
Hey @sromero,
I don’t have any new information than I did a few years ago. Could you clarify why the workaround @VakalosMixalis would not work? Namely, have you tried wiki/api/v2/pages?id= 90101010,9101010101?
Hi,we created 2 Confluence spaces with approximately 60 pages each. The pages were created successfully and could be accessed immediately through the Content REST API using their page IDs. However, they were not immediately available through CQL search.
The CQL request we are using is:
/wiki/rest/api/content/search?cql=%28Type%3Dpage+or+Type%3Dfolder%29+and+ID+in+%28983042%29
Which corresponds to:
(Type=page or Type=folder) and ID in (983042)
When we executed this request shortly after creating the page, CQL returned no results, even though the page could be retrieved successfully using GET /wiki/rest/api/content/{pageId}.
We waited approximately 24 hours and the page was still not returned by CQL. After approximately 2 days, the page finally became available through CQL.
This seems to indicate a significant delay in the Confluence search indexing process. The pages exist and are accessible through the REST API, but they are not searchable through CQL until a much later time.
Could you please confirm whether a delay of up to 2 days for newly created pages to become available through CQL is expected behavior? If not, could you please investigate whether there is an issue with the search index or indexing process for these pages/spaces?
There’s no published SLO for indexing. What everyone has described here is the behavior of “eventual consistency”. To my knowledge, there isn’t any acknowledged bug or issue about this.
I’ll admit that 2 days does seem like a long time for a typical definition of “eventual”. If there are specific sites, spaces, or pages where this is happening repeatably, then the path for investigation would be through developer support because they have to tools to research by looking into logs and obtaining customer permissions in a way that meets audibility requirements. When you raise a request, please capture the CQL, timestamps, and request/correlation IDs provided in the HTTP headers. I recommend reporting this as an “incident” (not a bug/issue) because of the real-time impact (classification may depend on who/what sites are impacted).
My interpretation of the opening post was the author for was looking an answer to a question about a change in behavior. Unfortunately, I could not and still cannot confirm (or deny) a change in behavior; hence, I can’t explain it. So, putting aside the case-by-case incidents, the practical thing to do in the face of eventual consistency is not to depend on CQL this way. Use CQL only for discovery of things your app doesn’t know. Eg, after the app creates a page, persist the returned page ID, and use a direct get-by-ID endpoint. The “workaround” from the opening post is actually the recommended approach not an exception.