we are using inlinetasks/search endpoint to fetch tasks in our app. We always set query parameter pageId to filter tasks from specific pages. We observed that endpoint returns some irrelevant tasks, i.e., tasks from pages that are not mentioned in the parameter. Example (GET) call: /wiki/rest/api/inlinetasks/search?status=incomplete&limit=500&pageId=97746957
In my case, it returns the following response:
Note that only one task should be returned.
After some investigation, we found out that the reason is that these pages have the parent:child relation. If you call the endpoint with the parent ID, it returns also tasks from the child page.
Is there a way how we can avoid this?
This sounds like a case of the API is doing the right thing, but the documentation doesn’t call it out.
Am I correct in thinking that it’d be helpful if the docs were updated to call out that children will also be returned and you’ll need to filter out those tasks on your end if you don’t need them?
Hello @bentley, thank you for the reply!
I think the current behavior is unexpected considering other endpoints and the role the pageId parameter usually has. It took us a while to find out where the extra tasks came from.
Unfortunately, in our case, we are using pageId multiple times, which may require result pagination. As the number of tasks can be high even without this behavior, retrieving extra tasks might be a huge problem in our solution (consider the situation where we ask for parent page that has many children with many tasks). This situation is not ideal for us but if it cannot be changed, it would be great to mention it in the documentation.
Thank you.
In addition to what @marketa.jancova wrote, may I ask what lead you to this conclusion? If I compare this to any other (imaginary) endpoint where you can do something like:
/rest/api/comments?pageId=123
Then I expect to only get comments that belong to the page with ID 123. If in the response there are comments that belong to pages with other IDs, then that’s just not what I’ve asked the API for. (no matter in what relation those other pages stand to the original page)
In fact, I struggle to come up with an actual use case where you’d only do ?pageId=123 but actually wanted tasks that are on child pages of page 123. To me that just sounds like a bug.
If I wanted tasks/comments/whatever that are on child pages of the original page I’d expect to have to do something like:
This comes from my assumption that this endpoint was added because someone needed to build some specific feature and they intentionally added in child subtasks because they needed them. Whoever added the endpoint is using it and knowingly filtering out child page subtasks and it is working just fine for them despite it doing something unintuitive.
Yes, that’d make a lot of sense. Like the children.page value for the expand query parameter on the GET content route, I’d expect a better version of this route to let you explicitly say whether you want child page tasks or not.
In my mind, it’d be a bug if it was previously doing something differently and started doing something new. But if it has always done this and people are using it already with the assumption that it is going to return child page tasks, then the documentation should be updated to call out this unintuitive behavior–this doesn’t mean it can’t also be improved! I’m also wet behind the ears when it comes to the Confluence Cloud API. The API endpoint development pattern I described comes from working on that other product with lists and cards .
So I guess a follow-up question is, has it started doing this recently or has it always done this?
You’re right about that! Back when Shrey was still there, they added this endpoint for us so we could build a Cloud version of Task Reminder for Confluence.
But we actually never asked for this specific feature/parameter. I’m not sure if someone else was involved when they built that endpoint, but I’m actually somewhat sure that we were the only vendor asking for this.
Makes sense!
We only started using this parameter now to build a new feature. I’m actually not sure if someone else used it before, because as I mentioned, this was built for us. Back when the endpoint was implemented for us we actually found some bugs that are similar to this one as well, which then were quickly fixed. I might be wrong, but I assume that simply nobody has ever stumbled upon this so far.
Either way, I get your reasoning now, and it makes sense that it can’t be changed if there are actually other apps relying on this mechanism. Thanks for clearing it up!
I guess for us this now means that we’ll have to scratch the feature we wanted to build.
Cheers,
Sven
P.S.: I got a desktop notification about your reply as I still had this page open in another tab
It seems that in production some customers simply have so much data, that we ran into the 15 minute lambda timeout (where previously our lambdas were taking only around 15-30 seconds). This is not so much because of the filtering itself, but because we had to do a lot more requests because of pagination.
,
.
