Conversations->list() doesn't fetch updated data correctly

[ghost]

I'm using conversations->list($filters->withQuery('assigned:"Unassigned"')) to get a list of all the unassigned tickets from a mailbox. I then assign a specified number of tickets to the current user like so: $this->client->conversations()->assign( $conversation->getId(), $userid );

I trigger this code from a slack command and I need the code to run multiple times in a row. For this I added a lock procedure, so that the concerned method only runs a single instance at the time.

• PHP version: 7.4
• SDK version: 3.0.1

Current behavior conversations()->list does not update the changes made when calling the method right after making the changes. For example: conversations()->list returns 50 conversations, I assign 18 conversations and call conversations()->list again. A list of 43 might be returned, but not of 32 as expected. A sleep(x); statement between the calls improves the issue.

Expected behavior The expected behaviour is, that when the method is triggered the second time, the list of unassigned conversations is up to date according to the changes made and that no already assigned conversations are fetched again.

Steps to reproduce

1. create a HelpScoutClient with 'auth' => [ 'type' => 'client_credentials', 'appId' => '', 'appSecret' => ''
2. call $this->client->conversations()->list($filters->withQuery('assigned:"Unassigned"') );
3. call $this->client->conversations()->assign( $conversation->getId(), $userid ); several times for different conversationt
4. call $this->client->conversations()->list($filters->withQuery('assigned:"Unassigned"') ); again -> count of all conversations is still the same or not entirely up to date to the assigned conversations

[JonLaliberte]

I believe there is just some lag in HS's data updating that you'll need to account for. You can see the same thing happening in the UI if you make bulk changes (say, close 50 conversations at once), it takes a few seconds before they are fully reflected in the UI. I suspect this is the backend taking time to reflect the changes - which you're also seeing when using the API.

[bkuhl]

Hey @alexshanmugam,

The conversation list endpoint is supported by a search service that requires reindexing of conversations when changes are made. This reindexing often only takes a few seconds (depending on system load at the time). Immediately calling list() may present the same or a similar list if the reindexing hasn't yet been processed for those conversations.

I think a good approach in this scenario would be to not immediately make changes to the conversations as you're filtering through the paginated results, but go through all the pages of results, compiling a list of conversations you'd like to update and updating them after you've paginated through all the results.