Performance of pruneConversationUpdateForLogging extremely slow

Hi all,

We are noticing degraded performance of our Angular web app whenever we mute/unmute or hold/unhold a call. After debugging we see that the cloneDeep() lodash function used by pruneConversationUpdateForLogging(update) function in the softphone-session-handler.js is taking up to 45 seconds. During those 45 seconds our web app is completely unresponsive (the call is not dropped).
After the freeze we get these warnings in the console:
[Violation] 'message' handler took 44229ms

I noticed other threads about cloneDeep (The cloneDeep method of lodash has serious performance bug · Issue #5535 · lodash/lodash · GitHub) which might have an impact?

Current versions of our genesys libraries:
genesys-cloud-webrtc-sdk: "9.2.0"
genesys-cloud-client-logger: "4.2.12"
genesys-cloud-streaming-client: "17.2.3"
purecloud-platform-client-v2: "185.0.0"

Reverting back to:
"genesys-cloud-webrtc-sdk": "9.0.2"
Fixed the issue.
Could you investigate why the latest version is giving errors?

Hey, glad to hear that reverting seems to have solved your issue. We're actually in the process of fixing some issues with deep cloning in a couple of our other projects, genesys-cloud-client-logger included.

I'll bring this up with the dev that's been working on that and get him to take a look at this and see if we can get it removed.

@Nils I've started looking into this and I have a lead on a possible solution.

But to clarify your scenario, are you running into this delay immediately with a conversation or does the delay build up over time? Could you describe the kind of conversation a bit (e.g. conference call with many participants, multiple transfers, lots of small actions like muting)? That'd be helpful to validate I'm solving the right problem as I haven't yet run into this exact issue.

Hi Jon,

We are running into the delay immediately. I tested this scenario:
I call to our contact center from my own phone. This call is redirected to my agents queue. I pickup the call. (no issues until here). The moment my agent clicks the "mute" or "hold" button the delay happens. It sometimes takes about 2 seconds to get the conversationUpdate event, other times it takes up to 45 seconds.
So it happened on the first mute and all subsequent mutes/unmutes as well.

We merged in a fix that should address this and will be part of the next release. I expect that to be available this week. Let us know if you still see the issue, though!

v9.2.2 of the SDK was released earlier today and includes the fix that should resolve this issue.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.