Legacy Dev Forum Posts

 View Only

Sign Up

Notifications API: Using v2.routing.queues.{id}.conversations.calls on one queue produces 6 messages when a call enters the queue

  • 1.  Notifications API: Using v2.routing.queues.{id}.conversations.calls on one queue produces 6 messages when a call enters the queue

    Posted 06-05-2025 18:19

    draeder | 2021-04-15 01:22:51 UTC | #1

    I have a simple test application using the Notifications API to monitor whether or not a call entered a queue by its queueId. It is working, but for some reason when a call enters, I get 6 messages from the Notifications API about that call. There is no difference between any of the messages. I would expect to get only one message from the API for a new call that entered the queue.

    Further, when the call disconnects, another message is emitted by the API that has the connectedState of "connected", which doesn't make any sense because I would expect the API to only emit when the connectedState for that call changes, and upon disconnect I would expect that connectedState would be "disconnected", not "connected".

    I can confirm I am not creating multiple websockets, because I avoid that with:

            if (ws.readyState === WebSocket.OPEN) {
                return
            }

    Could you help me understand why I'm getting 6 messages for every new call that enters queue, and 1 message that says the call state is connected when the call disconnects?

    Here is my code:

        const client = platformClient.ApiClient.instance
        client.setAccessToken(serverAuth.access_token)
    
        let apiInstance = new platformClient.NotificationsApi()
        
        apiInstance.postNotificationsChannels()
        .then ( channelData => 
        {
            const ws = new WebSocket(channelData.connectUri)
            if (ws.readyState === WebSocket.OPEN) {
                return
            }
            console.log("New websockets channel created")
            
            ws.onerror = error => {
                console.log('Connection Error', error)
            }
    
            ws.onclose = () => {
                console.log("Websockets connection closed")
            }
    
            ws.onopen = () => {
                console.log("Channel connected")
            }
    
            ws.on("message", msg => {
                conversations = JSON.parse(msg)
                
                for(item in conversations.eventBody.participants){
                    let call = conversations.eventBody.participants[item]
                    if(call.direction == "inbound" && call.state == "connected" && call.purpose == "acd"){
                        console.log(call)
                        console.log(call.connectedTime)
                        console.log()
                    }
                }
    
    
            })
    
            let channelId = channelData.id
    
            apiInstance.postNotificationsChannelSubscriptions(channelId, monitoredItems)
            .then(channelData => {
                console.log("Subscribed to the channel successfully")
            })
            .catch( err => {
                console.log("There was a failure subscribing to a channel")
                console.error(err)
            })
    
        })
        .catch ( err => 
        {
            console.log("There was a failure creating the channel")
            console.error(err)
        })

    If I should open a case with support on this, please let me know...

    Thanks, Dan


    tim.smith | 2021-04-15 13:23:20 UTC | #2

    Conversation notifications are generated any time anything about the conversation changes, not just state changes. Notifications may even appear to be exact duplicates since changes that aren't exposed publicly can still trigger a notification. Well-formed applications will diff the state of the conversation with the last known state each time a notification arrives to determine what changed and then trigger the desired business logic based on those changes.

    If you need to track down exactly why a specific notification was raised, please open a case with Care to investigate as customer data cannot be investigated on the forum.


    draeder | 2021-04-15 14:20:53 UTC | #3

    Thanks Tim - That makes a lot of sense and answers a different question/issue I've noticed with another endpoint. Much appreciated!


    draeder | 2021-04-17 01:07:37 UTC | #4

    Hi @tim.smith ,

    Just a quick followup question: Isn't it possible to prevent the emit to the public API when only internal (non-public) changes are occur? I've worked with many websockets apis and have never experienced this kind of thing with those other apis. The need to diff each message to find out if there was a change between the new one and the last one puts extra load on the sever, and it seems unnecessarily so.

    Thanks, Dan


    system | 2021-05-18 00:37:41 UTC | #5

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


    This post was migrated from the old Developer Forum.

    ref: 10640