Re: GraphQL Pagination Cursors: 504 Gateway Time-out Responses

BlakeR · ‎10-24-2022

We are using the GraphQL API Search (https://github.com/CiscoDevNet/webex-contact-center-api-samples/blob/main/graphql-sample/README.md) to pull TaskDetails in up to 24-hour periods. Before last week, this was working well and we were able to pull a full day's worth of over 30+ pages using Cursors. Now, it is only making it about 5 to 7 pages before hitting a scenario where the ‘endCursor’ under ‘pageInfo’ skips a number, i.e. Cursor 5 skips 6 and claims 7 is next, which is then followed up by a 504 Gateway Timeout Response. This is making querying for long periods fail every time.

504 Response from our logs:

Response: 504
Headers: {"server"=>["awselb/2.0"], "date"=>["Mon, 24 Oct 2022 18:41:41 GMT"], "content-type"=>["text/html"], "content-length"=>["132"], "connection"=>["keep-alive"]}
Body: <html>

<head><title>504 Gateway Time-out</title></head>

<body>

<center><h1>504 Gateway Time-out</h1></center>

</body>

</html>

GraphQL Query Used:

{ # The following sample aims to pull a complete data set of all Contact fields from the GraphQL API
taskDetails(
from: date_from_variable,
to: date_to_variable,
pagination: { cursor: "cursor_variable" },
timeComparator: endedTime, # When filtering tasks, use the end time of the task
filter: {
and: [
{ isActive: { equals: false } } # Resolved call only
]
}
) {
tasks {
id # (sort: SortOrder): String
# ID of the task.

status # (sort: SortOrder): String
# Current status of the task. Some examples of possible values are: new, parked, connected, ended.

channelType # (sort: SortOrder): String
# The media channel through which the task will be fulfilled. Can be telephony, email, or chat.

createdTime # (sort: SortOrder): Long
# Created time of the task (epoch milliseconds).

endedTime # (sort: SortOrder): Long
# Time of completion of the task (epoch milliseconds).

origin # (sort: SortOrder): String
# Customer's channel-specific identifier. For telephony, this is the phone number. For email and chat, this is the email address.

destination # (sort: SortOrder): String
# Destination the customer contacted. For telephony, this is the number the contact called. For chat, this is the URL of the page where the chat takes place. For email, it is the email address contacted.

contactReason # (sort: SortOrder): String
# Indicates the category/reason that is selected when initiating an interaction from native digital channels like chat.

direction # (sort: SortOrder): String
# Indicates which party initiated the Task. If inbound, call was initated by customer. If outbound, was initiated by system as part of campaign. If outdial, was initiated by an agent.

owner { #: AgentInfo
# Current owner of the task
id # (sort: SortOrder): String
# ID of the agent last assigned to this task.
name # (sort: SortOrder): String
# Name of the agent last assigned to this task.
}

terminationType # (sort: SortOrder): String
# A computed value which indicates how the call was terminated.

channelSubType # (sort: SortOrder): String
# Indicates the classification of a particular channel type. For e.g. for social channel, twitter is a sub channel type.

customer { # : CustomerInfo
# Customer's identifier (phone number or email).
name # (sort: SortOrder): String
# A human-readable name of the end customer.
phoneNumber # (sort: SortOrder): String
# A valid customer DN, on which the agent can reach out to the customer.
email # (sort: SortOrder): String
# A valid email address on which the agent can reach out to the customer.
}

isActive # (sort: SortOrder): Boolean
# Indicates if the task is resolved(if false) or open(if true).

isCallback # (sort: SortOrder): Boolean
# Indicates if the call is a callback(if true) or not callback(if false).

channelMetaData { # : ChannelMetaData
email { # EmailInfo
# Additional information on the incoming task channel.
subject # (sort: SortOrder): String
metaData # (sort: SortOrder): String # Returning an error as of 2022-10-14
}
}

callbackData{ # : CallbackData
# Information on the callback data of the call.
callbackRequestTime # (sort: SortOrder): Long
callbackConnectTime # (sort: SortOrder): Long
callbackNumber # (sort: SortOrder): String
callbackStatus # (sort: SortOrder): String
callbackOrigin # (sort: SortOrder): String
callbackType # (sort: SortOrder): String
}

recordingLocation # : String
# The location of the conversation record file.

lastWrapupCodeName # (sort: SortOrder): String
# Indicates the wrap-up code the agent gave for the given contact for the task. E.g. sale

lastQueue { # : QueueInfo
# Queue Information
id # (sort: SortOrder): String
# The id of the queue where the task is lined up.
name # (sort: SortOrder): String
# The name of the queue where the task is lined up.
duration # (sort: SortOrder): Long
# The amount of time(in epoch millis) the task was lined up in the queue.
}

lastSite { # : NameIdInfo
# Id, name of the contact center location to which the task was distributed.
id # (sort: SortOrder): String
name # (sort: SortOrder): String
}

lastTeam { # : NameIdInfo
# Id, name of the contact center team to which the call was distributed.
id # (sort: SortOrder): String
name # (sort: SortOrder): String
}

lastEntryPoint { # : NameIdInfo
# Id, name of the the outdial entry point provisioned for outbound (outdial) customer chats, calls, or email tasks in the Webex Contact Center system.
id # (sort: SortOrder): String
name # (sort: SortOrder): String
}

totalDuration # (sort: SortOrder): Long
# Metrics

csatScore # (sort: SortOrder): Int
# Represents the customer satisfaction score.

blindTransferCount # (sort: SortOrder): Int
# The number of times a task was transferred out of the queue by the agent without consulting first.

conferenceCount # (sort: SortOrder): Int
# The number of times the agent established a conference call with the caller and another agent.

conferenceDuration # (sort: SortOrder): Long
# The amount of time an agent spent in conference with the caller and another agent.

consultCount # (sort: SortOrder): Int
# The number of times agents initiated a consult with another agent or someone at an external number while handling a task.

consultDuration # (sort: SortOrder): Long
# The amount of time an agent spent consulting with another agent while handling this task.

holdCount # (sort: SortOrder): Int
# The number of times a caller was put on hold.

holdDuration # (sort: SortOrder): Long
# The amount of time the call was on hold in this queue (for a queue CDR) or in all underlying queues (for an entry point CDR).

selfserviceCount # (sort: SortOrder): Int

selfserviceDuration # (sort: SortOrder): Long

connectedCount # (sort: SortOrder): Int
# The number of tasks that got connected to an agent.

connectedDuration # (sort: SortOrder): Long
# The total duration for which the agent was in conversation with the customer for a task.

consultToQueueCount # (sort: SortOrder): Int
# The number of times consult-to-queue requests were initiated.

consultToQueueDuration # (sort: SortOrder): Long
# The cumulative amount of time between when consult-to-queue requests were initiated and when the consultations ended.

transferCount # (sort: SortOrder): Int
# Number of times a contact is transferred.

wrapupDuration # (sort: SortOrder): Long

ringingDuration # (sort: SortOrder): Long

queueDuration # (sort: SortOrder): Long
# The cumulative amount of time calls were in queue, waiting to be sent to an agent or other resource.

queueCount # (sort: SortOrder): Int
# The number of calls that entered the queue during this interval.

captureRequested # (sort: SortOrder): Boolean
# Indicates that recording is available or not.

queues{ # : [QueueInfo]
# Queue Information
id # (sort: SortOrder): String
# The id of the queue where the task is lined up.
name # (sort: SortOrder): String
# The name of the queue where the task is lined up.
duration # (sort: SortOrder): Long
# The amount of time(in epoch millis) the task was lined up in the queue.
}

sites { # : [NameIdInfo]
# Id, name of the contact center location to which the task was distributed.
id # (sort: SortOrder): String
name # (sort: SortOrder): String
}

teams{ # : [NameIdInfo]
# Id, name of the contact center team to which the call was distributed.
id # (sort: SortOrder): String
name # (sort: SortOrder): String
}

entryPoints { # : [NameIdInfo]
# Id, name of the the entry point provisioned for tasks in the Webex Contact Center system.
id # (sort: SortOrder): String
name # (sort: SortOrder): String
}

contributors{ # : [AgentInfo]
# Agents who have handled the task
id # (sort: SortOrder): String
# ID of the agent last assigned to this task.
name # (sort: SortOrder): String
# Name of the agent last assigned to this task.
}

integerGlobalVariables(name: "AccountId") {
name
value
}
stringGlobalVariables(name: "CustomerId") {
name
value
}
booleanGlobalVariables(name: "VIPCustomer") {
name
value
}
}
# Pagination Information
pageInfo {
endCursor
hasNextPage
}
}
}

Arunabh Bhattacharjee · ‎11-02-2022

This is a known issue that is being worked on internally. ETA is 3 weeks for the deployment.

For additional follow ups on 5xx errors please contact Cisco TAC as per regular process.

Thanks & Regards,

Arunabh.

Arunabh Bhattacharjee · ‎10-30-2022

Hi @BlakeR

This seems to be an issue on the backend that was short lived and an incident was opened for this. Is this issue still persistent?

There has also been a change in the circuit breaker implementation that will lead to client side errors for malformed / very large queries but those should start from page 1.

Please confirm that you are still seeing these issues - we are also investigating this internally.

Thanks & Regards,

Arunabh.