Some data out of order when listing conversations

#1

Hello, I am trying to retrieve all conversations sorted by updated_at such as using https://api.intercom.io/conversations?page=1&per_page=50&order=desc&sort=updated_at

Most of the items are in order but I notice a couple of conversations per page that clearly don’t belong on the page – as in most of the results will have an updated_at that falls within a 4 hour window, but then a couple of them might be 2 weeks outside of that range, for example.

Is this a known issue and what can I do to ensure that we correctly fetch all of the conversations updated within a given time interval?

We are using version 1.0 of the API. Specific details can be provided in a private message. Thanks.

0 Likes

#2

Hi :wave: I’ve picked up your conversation within Intercom so let’s first investigate that and see what we find out there :+1:

0 Likes

#3

After chatting with our team seems that this is indeed a bug that we’re tracking :+1:

If anybody else runs into this, let us know within Intercom to ensure that we can get back to you when it is fixed :muscle:

0 Likes

#4

Hello Tim,

We are having new issues with this bug while planning how to consume/process the data, can you share more information related to this issue?

Some questions that we came up with:

  • Is this bug restricted to Conversations? Are Users affected by this?
  • Do you think ‘page size’ parameter has any relation with the issue?
  • This seems to be happening with created_at, is there any other property that might be affected as well?
  • Does it affect the scroll api?
  • Is there anything that we can do to mitigate this behavior?
  • Is this planned to be fixed in the listing API? ETA?
  • Is there any other API that we could use to gather this data (Bulk or similar)?

Our initial guess was that this happened to some sporadic conversations but found out multiple consecutive missplaced conversations. Do you think there might be a pattern (for instance. misplaced conversations will be coming in batches of 5 or fewer conversations)?

Thanks

0 Likes

#5

Hi @tim.lim, do you have any update on this topic?

0 Likes

#6

Hi @Jorge_Artave :wave: Welcome to the forum :smile:

The bug essentially is that when listing conversations and sorting them by updated_at/created_at, there can be some conversations which are returned with a timestamp value that is out of order with respect to the rest

Is this bug restricted to Conversations? Are Users affected by this?

The issue that we have documented internally only affects Conversations. If you are seeing it on users, do share some details on it here (or if it contains possible user information do share it with us in our Messenger / chat)

Do you think ‘page size’ parameter has any relation with the issue?

Page size is not a factor in relation to the issue

This seems to be happening with created_at, is there any other property that might be affected as well?

Both updated_at and created_at are affected. Currently I’m double checking to see if waiting_since is affected and will give you an update when I have it

Does it affect the scroll api?

The scroll API is only for users, leads and companies and not conversations so it isn’t affected by the same issue :slight_smile:

Is there anything that we can do to mitigate this behavior?

Not at the moment. The issue lies in the backend

Is this planned to be fixed in the listing API? ETA?

Yes it is being planed, but no specific ETA at the moment. If you send us a message via Intercom we can add you to the tracking issue so that we can reach out when it is fixed :+1:

Is there any other API that we could use to gather this data (Bulk or similar)?

Depending on the data you’re looking to extract there could be ways to what you need so please share a bit of details and I’ll see what can be done

Our initial guess was that this happened to some sporadic conversations but found out multiple consecutive missplaced conversations. Do you think there might be a pattern (for instance. misplaced conversations will be coming in batches of 5 or fewer conversations)?

The issue lies in our data in the backend and how we update the data based on different interactions. I think this situation could be coincidental and perhaps those conversations had similar interactions which caused the same kind of updates to happen

0 Likes

#7

@EtleapDev We are still tracking this internally and there has been some work to identify the core problem but we don’t have any ETA on a fix just yet

0 Likes