queued calls disappear from /search API response

[jcombs10]

I'm using the graphql search API to gather info on calls currently in queue awaiting an agent (calls in a parked state if I'm understanding correctly).  I can see a call in a parked state but after some time (usually ~30 seconds), the call vanishes.  It doesn't become a callback nor an abandoned call, it's just gone.  If I re-run my query and look for the task id from the previously parked call it's nowhere to be found.  I came back like an hour later and again re-ran my query and the call is back with a terminationType of "normal". suggested sometime during that period when it had vanished it was connected and completed by an agent successfully.

What happened to the task during this period of time?

My search query:

query($fromTime: Long!, $toTime: Long!)
{
    task(
        from: $fromTime 
        to: $toTime 
        timeComparator: createdTime
        filter: {
            and: [
                { direction: { equals: "inbound" } }
                { channelType: { equals: telephony } }
                { or: [
            ]
        }
    ) {
        tasks {
            id 
            createdTime
            endedTime
            entryPoint {
                name
            }
            terminationType
            owner {
                name
            }
            isActive
            isCallback
            status
            queueDuration
            connectedDuration
            totalDuration
            holdDuration
            wrapupDuration
            selfserviceDuration
            ringingDuration
            destination
            lastQueue {
                name
                id
            }
            lastTeam {
                name
                id
            }
            origin
            destination
            contactReason
            direction
            terminationType
            customer {
                name
            }
            callbackData {
                callbackNumber
            }
        }
        pageInfo {
            hasNextPage
            endCursor
        }
    }
}

[jcombs10]

The sequence of state transitions makes sense.  The question is why does the call exist in my search result at 12:52:30 (approximately) but not in my search result when executing the same query at 12:55:00 (approximately)

If they were still sitting in a parked state shouldn't every invocation of my search query between 12:52:24.643 and 12:58:20.780 have included that call in the result set?

[sdoddali]

That is correct, In this case, you should see it as parked between 12:52 to 12:58.

The total records for 'task' object per page is 500, I see you are passing 'hasNextPage' parameter, Do you know if that was true by any chance?

Do you have the complete output of the query you ran at 12:55 that I can review? 

[jcombs10]

I've attached query results from when it first entered a parked state as well as a couple minutes later when the parked call had vanished.  Note that it may not have been precisely 12:55 but it was definitely prior to the call being connected.  I don't have the exact time but it was probably closer to 12:53:30 or so.

My from time on this was actually started of the work day (8 AM).  Also, my query had an or condition to select tasks for 5 or 6 queues since I didn't know which one was going to experience this strange behavior and I wanted to make sure I could capture it.  Despite that the volume on these queues is low enough that we did not paginate.  hasNextPage was false on every query response.

tasks_with_call_on_hold.txt - this was the first query execution when I initially observed a parked call.  By my count there are 185 tasks in this response

tasks_with_call_missing_from_response.txt - this was a second execution of the same query somewhere around 12:53:30 or so when the call would still have been in a parked state according to the timeline above.  I count 184 tasks in this response.

tasks_with_call_reappeared.txt - a third execution of the same query a couple hours later, long after the call had completed and it shows back up in the search result.  I see 306 tasks in this response.

This happens with every call that enters a parked state due to no available agents so I can reproduce it pretty easily and grab additional samples if needed.

[sdoddali]

I do see in the backend you ran the query at the correct time to get that particular call in a parked state.

// Your first query.

Apr 3, 2023 @ 12:52:46.983  - {fromTime=1680497566604, toTime=1680540766604}

Result count: 185

// Your second query 

Apr 3, 2023 @ 12:53:19.646  {fromTime=1680497599407, toTime=1680540799407}

Result count: 184

// I don't see a reason why that call would not show up.

Probably you can run a query with the following filter when a call does not show up in the parked state and check what the output is.

filter: {

and: [

{ direction: { equals: "inbound" } }

{ channelType: { equals: telephony } }

{ id: { equals: "2d646729-6bc5-4a16-80f2-a4f9e8c1f956" } }

]

}

// This will provide some insights into what was the actual state of that call according to the graphQL server. 

[jcombs10]

I've been out of the country so I haven't had a chance to do anything with this.  Before I left I did come at this from a slightly different angle and executed the /v1/tasks GET endpoint rather than the /v1/search POST endpoint.  On the GET endpoint I could see the task with a status of "queued" in that response even though it did not come back on the search endpoint.

It's as if the /v1/search endpoint ignores a status of queued even though there is not status filter in my query.

I'll try to catch a case of this today and run the search query with the task ID filter as you suggest.

[sdoddali]

Hello Jcombs10,

Do you mean you place a call and park it, when you run query initially you will see the parked call from your above query, But after 30 seconds, the query does not return anything.

What are the values of to and from you are passing?

-Thanks,

Shrishail 

[jcombs10]

I'm passing the current system time in millis as the 2 and the from is to time minus an hour (3600000 ms)

It's not so much that I'm placing the call as I'm watching the flow of things in our call center.  When there are no available agent and a call arrives that call goes into a parked state if I'm understanding correctly.  This is supported by what I see in my first query in that I see a call in a parked state:

{
    "id": "a0be1129-1c5f-4039-946c-1631f5db0ddc",
    "createdTime": 1680540737197,
    "endedTime": -1,
    "terminationType": null,
    "isActive": true,
    "isCallback": false,
    "status": "parked",
    "queueDuration": 0,
    "connectedDuration": 0,
    "totalDuration": 0,
    "holdDuration": 0,
    "wrapupDuration": 0,
    "selfserviceDuration": 6704,
    "ringingDuration": 0,
    "lastQueue": {
        "name": "MY QUEUE NAME",
        "id": "055577f6-0681-4c01-b2d5-ecc24467a4ab"
    },
    "direction": "inbound",
    "callbackData": {
        "callbackNumber": null
    }
}

My query is pretty broad, looking at all tasks for that queue during the time window, but the call center is low volume so I'm certain the result set isn't paginating.  All tasks fit into the query response.  If I re-run my query 30 seconds to a minute later the result set no longer contains a task with the id of the parked task that was present in my first query.  An hour or so later I ran my query for a 3rd time and the task with that id was again present in the result set with a terminationType of normal and a status of ended

[sdoddali]

The graphQL endpoint shows only one active state of the call at any given point in time.

Let's say a call comes in and gets parked - your query will show that call as parked.

After the parked state, if the agent becomes available then the state of the call will change to connect (while ringing to an agent) and then to connected(once it's connected to agent).

For the above interaction which you shared, here are the different states that the call went through.

a0be1129-1c5f-4039-946c-1631f5db0ddc 

// The call was in the parked state for ~5mins before moving to 'connect', at that point you should start seeing the call with status as 'connect' and then 'connected' and so on...

Let me know if that clarifies your question.