When making the 'patchConversationIdParticipantsParticipantIdWithHttpInfo' to hold/retrieve operations, I randomly get 400 with different error messages.
Any ideas on what might be causing this or how to fix it?
Error1:"bad.request","message":"Wrap-up cannot be skipped for this participant."
21:31:07,728 ERROR [stderr] (GT-X UniversalController_0jniHXyJNeoLwljQ-z5QCuUG.localhost-ekp_1) com.mypurecloud.sdk.ApiException: {"status":400,"code":"bad.request","message":"Wrap-up cannot be skipped for this participant.","contextId":"e21d7ace-6f10-48da-ac96-ad600f86bfb7","details":[],"errors":[]}
21:31:07,730 ERROR [stderr] (GT-X UniversalController_0jniHXyJNeoLwljQ-z5QCuUG.localhost-ekp_1) at com.mypurecloud.sdk.ApiClient.invokeAPIVerbose(ApiClient.java:651)
21:31:07,730 ERROR [stderr] (GT-X UniversalController_0jniHXyJNeoLwljQ-z5QCuUG.localhost-ekp_1) at com.mypurecloud.sdk.api.ConversationsApi.patchConversationIdParticipantsParticipantIdWithHttpInfo(ConversationsApi.java:3060)
Error2:"bad.request","message":"The participant for this request cannot be confined."
21:31:50,244 ERROR [stderr] (GT-X UniversalController_0jniHXyJNeoLwljQ-z5QCuUG.localhost-ekp_1) com.mypurecloud.sdk.ApiException: {"status":400,"code":"bad.request","message":"The participant for this request cannot be confined.","contextId":"bc668657-459d-4846-8ab4-277edafc8c70","details":[],"errors":[]}
21:31:50,244 ERROR [stderr] (GT-X UniversalController_0jniHXyJNeoLwljQ-z5QCuUG.localhost-ekp_1) at com.mypurecloud.sdk.ApiClient.invokeAPIVerbose(ApiClient.java:651)
21:31:50,245 ERROR [stderr] (GT-X UniversalController_0jniHXyJNeoLwljQ-z5QCuUG.localhost-ekp_1) at com.mypurecloud.sdk.api.ConversationsApi.patchConversationIdParticipantsParticipantIdWithHttpInfo(ConversationsApi.java:3060)
Those error codes are dependent on both the conversation state and the body that you are providing in the patch request. Looking at the first example it seems like you are skipping wrapup in a situation that it is not permitted. Can you include the bodies you are specifying when making these requests and a description of what you are attempting to achieve along with any relevant Ids?
I am not setting anything for the wrap up object but I don't get the error all the time. IF I have understood what you are saying, should I not be getting this error all the time?
Secondly, I don't really want to wrap up when I am performing call controls such as Hold/Retrieve. I would prefer to do it at the end when the call is dropped/disconnected.
If I wrap up when performing call controls do i need to perfrom wrapup again at the end when the call disconnects?
You should only get that error if you are setting the wrapupSkipped property in your request body. Having the body of the request that you sent when you got that specific error would help troubleshoot if you don't think you should be receiving it.
The second error is because a confine is being requested in the wrong scenario. We only support confining a participant on a conference call.
If you are getting these errors at times that don't make sense, let me know what you have specified in the request you made and I can help troubleshoot further.
I see that you are using one of our SDKs so if the actual requests you are making aren't available to you that is fine. Just the arguments you are using to make those requests would be helpful.
I managed to get the first error to go away. But, I am not sure this is what I want to do. I had to setup the wrapup object and set it up before calling patchConversationIdParticipantsParticipantIdWithHttpInfo() APIs.
Does this mean if the call drops (either the user drops it or customer disconnects), I will get another call straight away?
Since I had to set the wrapup code to get rid of the above issue, I guess the wrapup code for is assumed to be set? So I will get another call straight away?
If you disconnect the call and also set the wrap up code (in either order), yes, you will get another call immediately.
"ACW" isn't a state/status in PureCloud. ACW is derived by computing the delta between the time the call ended and when the wrap up code was set. If the agent needs non-acd time between when they disconnect and set the wrap up code and when they get the next call, they need to go off queue before they finish their call. You can use custom statuses to allow the user to indicate why they're off queue (i.e. make a new status "ACW" that derives from the BUSY status) and can report on that.
So to me, it sounds like a bug that I am having to pass in a wrapup code to the API to get rid of the issue? And this is causing a new call to come through as soon as old one drops/disconnects.
Perhaps, I should only be setting the wrapup code when I an actually ready for another call?
Sorry, can you restate what your issue is and provide a correlation ID for a request that has the issue? Also grabbing the request body would be useful. From the thread, it just looked like you were making certain requests at inappropriate times (because of the errors you were getting).
We are also experiencing this issue. We have a correlation ID for the error below when we try to resume a call when we are using the ConversationApis patchCallsCallIdParticipantsParticipantIdWithHttpInfo() method. Also, we have just upgraded to the latest SDK available and are trying to get the additional log statements that you mentioned above in a previous post. However, we are only seeing log statements that include only the headers like below. We do not see the request/response log statements. Is there some logging configuration that we need to do?
I've asked someoene on the edge team to take a peek at that correlation ID to see if they can see exactly why it's failing. I can trace it back to the edge saying "resource not found", but I can't tell why it's saying out.
I've tested this out and it's working fine for me. The only thing I can think of that you might be doing wrong is that maybe you're grabbing the wrong participant ID (can't see your logic for getAgentParticipantId(...)), or maybe you're trying to take action on a participant that isn't active anymore. FWIW, here's my test code. You can run this to see if it behaves any differently for you.
To better understand the issue, how broad is this problem?
Does it affect one user, some users, or all users?
How frequent is the problem? Does this happen occasionally for hold requests, most of the time, or literally every time?
Does this issue happen for any other actions or just when trying to hold?
However, we are only seeing log statements that include only the headers like below. We do not see the request/response log statements.
I'm not sure what you're expecting to be traced out. In your code example, you're not assigning the response to the API call to a variable. Since you're not even getting a reference to the ApiResponse object, you can't be tracing out any of the information you get from it. My example code linked above demonstrates how to use the ApiResponse object to log info about the request/response.
Does it affect one user, some users, or all users?
1.) Seems to affect all users.
How frequent is the problem? Does this happen occasionally for hold requests, most of the time, or literally every time?
2.) Occasionally for hold/resume requests.
Does this issue happen for any other actions or just when trying to hold?
3.) So far, only hold/resume using ConvesationsAPI's patchCallsCallIdParticipantsParticipantIdWithHttpInfo() function.
My example code linked above demonstrates how to use the ApiResponse object to log info about the request/response.
In your example code, in the createUser() function, if it throws an ApiException then I don't believe any of those System.out lines will be executed which is what is happening for us. Regardless, I was able to capture the request body for a successful hold/resume request. I believe the requests getting the errors are probably the same since we're not changing anything besides the held boolean. wrapupSkipped is set to "false" which is probably the cause of us seeing the "Wrapped up skipped error".
I think that message is misleading and is most likely the result of the hold command failing. The platform API is probably sending a different error message because it's guessing which operation caused the error.
I'm still waiting on getting someone from the edge team to take a look to see if they can see why the hold operation is failing, but there's not a lot of priority given to non-support requests. Would you mind opening a ticket with PureCloud support for this? They should be able to get attention for this investigation faster than I can.
Put this at the beginning of your application to make it return the exception in the ApiResponse object instead of throwing it:
I've created API-2017 for this. The SDK shouldn't be sending values for optional parameters that you did not provide a value for. Specifically for cases like this, specifying the default values cause PureCloud to take an action on those parameters, which you did not intend. I don't expect that fixing this issue in the SDK will resolve the issue you're seeing, however.
I am keep on getting error while doing hold/resume/drop call today. Is this error is related to swagger definition it's generated from is wrong ? If so as a workaround should i set rest of the property is null ?
Caused by: com.mypurecloud.sdk.ApiException: {"status":400,"code":"bad.request","message":"The participant for this request cannot be confined.","contextId":"220a869a-fb2b-4d99-8800-6602a3d43d9c","details":[],"errors":[]}
Caused by: com.mypurecloud.sdk.ApiException: {"status":400,"code":"bad.request","message":"The participant for this request cannot be confined.","contextId":"9d2db051-7119-4126-bcfb-1079c81609a6","details":[],"errors":[]}