Channel counter in bridge instance in ChannelLeftBridge event returns incorrect value

[pavelsc]

Here is the code:

bridge.on('ChannelLeftBridge', (event, instances) => {
    var holdingBridge = instances.bridge;
    console.log(holdingBridge.id);
    console.log(bridge.id);
    console.log(holdingBridge.channels.length);
    console.log(bridge.channels.length);
    if (holdingBridge.channels.length === 0 && holdingBridge.id === bridge.id) {
        bridge.destroy((err) => {
            if(err){
                return;
            }
            console.log('destroyed');
        });
    }
});

and what is in output:

e3ea8e04-b9eb-4895-8754-27e4d1a94dad
e3ea8e04-b9eb-4895-8754-27e4d1a94dad
1
0

Is it considered a bug or it is supposed that original bridge should be used? Sometimes both counters returns 0.

[samuelg]

The bridge instance above would be a snapshot of the bridge at a particular time. The count associated with it would depend on where that instance came from. For example, if it's from the bridge creation I would expect the count to be 0. If it came from a channel joining a bridge it would be greater than 0.

I would not expect channels leaving a bridge to update the counts on all instances in memory. To get the current count you have to look at the instance returned along with the event.

[pavelsc]

But instance returned along with ChannelLeftBridge event returns 1, and in my particular case it is definitely incorrect because I create a holding bridge per every incoming channel, therefore bridge can never has more than one channel, which means that instance with this event should always return 0, but most of times it returns 1, and in 10% cases it returns 0. It does not break my code because there is no need in counter in my case, just wanted to notify that something goes wrong. Anyway thanks for clarifying, I thought ARI client keeps single instance and all other objects are just references

[samuelg]

All instances are snapshots. Events are typically needed to get the latest state of an instance. This may be an upstream bug in Asterisk, although I'm not sure what the expected behavior is there. I would submit an issue with Asterisk [1] to get clarification on this since this library simply passes along the values it gets from events.

[1] - https://issues.asterisk.org