Legacy Dev Forum Posts

Shaheem | 2020-10-29 07:41:24 UTC | #1

Hi guys,

I just wanted to verify if there is a behavior change with the channel creation with reference to the following announcement:

https://developer.mypurecloud.com/forum/t/exceeding-the-notification-channel-limit-will-attempt-to-remove-channels-without-an-active-connection/6796

The announcement says that new channel creation would:

1. Check for active connections first
2. Prefer to delete non-connected channels first
3. If channels are connected it would still delete the oldest channels.

What I have noticed is that channels are not being deleted/replaced at all when new set of channels are created by a different token of the same oauth. The channel creation requests succeed and return connection id and connectUri but posting subscriptions to those channels fail with the following error:

{"message":"The system was not able to get channel by id","code":"notification.unable.to.get.channel.id","status":400,"messageParams":{},"contextId":"xxxxxxxxxx","details":[],"errors":[]}

Upon checking the channels list I can still see the old (connected) channels still exists while the new channels which were created successfully (based on the response) are not available to be used and did not replace the old channels and give errors when you try to post subscriptions to it.

The use case I am having issue with is as follows:

OAuth 1 - Token 1 Creates 15 Channels out of the max allowed 20. Leaving 5 channels as unused. Everything is ok.

OAuth 1 Token 2 This token needs to create 15 channels as well. Previously when the new token created the new channels it would have used the 5 available channels and then bump 10 channels from the already used channels (i.e. delete the oldest channels first)

It seems there is a behavior change here as follows which is not mentioned in the announcement:

1. A token cannot delete channels created by other token now - This seems to be a new behavior. Previously the default behavior was that the channels would get bumped/deleted regardless of the token that created it. It seems to be a very important breaking change.
2. Channel creation request still seems to succeed for the second token while the channels are not available to be used - resulting in 400 error as mentioned above. I think the api should give an error that its cannot create the channels so that the client can handle the subscription process appropriately.

It would be great if someone could confirm this behavior

Thanks Shaheem

Shaheem | 2020-11-02 07:48:44 UTC | #2

Hi guys,

Any update on this please?

Thanks Shaheem

anon11147534 | 2020-11-02 17:49:42 UTC | #3

Hi Shaheem,

A member of the dev team is working on reproducing the issue now. We'll update you with the results.

joe.fruland | 2020-11-02 19:25:17 UTC | #4

Hi Shaheem,

Creating channels with a new token after reaching the limit for the user/oauthclient should successfully remove the oldest non-connected channel created by another token, and the new channel should accept subscription changes successfully. I attempted to reproduce your issue in our dev environment, and it appears to be working as intended.

Something that may be happening is that you are creating many channels in rapid succession with the new token, and it is causing newer channels to be deleted soon after being created. This can happen if the old channels remain connected and the new channels are not yet connected as you create more channels. If you would like to provide correlation IDs for the request that created a channel successfully and the following request to subscribe that failed, I could verify this is what is happening.

In order to prevent this from happening there are a few options:

1. Connect the websocket for each new channel before you create another channel.
2. Close the old websockets that you know are no longed needed before creating new channels.
3. Reduce the number of channels needed for each token so they can co-exist within the channel limit for your app.

Shaheem | 2020-11-03 00:48:30 UTC | #5

Thanks Ronan/Joe for the reply.

I don't think it’s the channel creation in rapid succession issue. Each channel creation takes some time to get created and to get a response. This process is done sequentially. Plus I can see in the scenario I mentioned earlier (also based on the channel limits) only 20 channels are allowed at any point in time and any channels created above this limit (which seems to be possible based on the response) are not eventually usable (cannot be posted to). So, the limit seems to be working on the part of posting the subscriptions to the channels (i.e. fails with the error)

This is an easy scenario to replicate. Just create and connect 15 channels with an OAuth token. Leave then connected and try and create another 15 channels with a new token. You would see that the second set of 15 channels (all) respond with a 200 ok response (together with the new connectUri and channel ids) but since the old channels are connected only 5 channels out of the new 15 are available to be used for subscription posting (i.e. 20 channel limits). The other 10 would throw the error as expected based on the limit with the new behaviour.

<ins>New Behaviour</ins>

OAuth1 - Token1 \------------------------------ Channels Created: 15 Channels Connected: 15 channels Available: 5

OAuth1 - Token2 \------------------------------ Channels Created: 5 (all 15 channels returned 200 OK response with channel details. But only 5 can be used - channel limit) Channels Connected: 5 (only 5 channels connected successfully. Program requires 15 channels to receive all notification udpates) channels Available: 0

• -

<ins>Old Behaviour</ins> <u>OAuth1 - Token1</u> \------------------------------ Channels Created: 15 Channels Connected: 15 channels Available: 5

OAuth1 - Token2 \------------------------------ Channels Created: 15 (used 5 available channels and bumped 10 connected channels created by Token1 ) Channels Connected: 15 (All new 15 channels are now connected and in use) channels Available: 0 (5 channels still connected and held by old token. Available to be bumped)

Based on the above old and new use case there is definitely a breaking behaviour change which is not mentioned in the announcement. Your reply is confirming there is a behaviour change as below

Based on the announcement it seems there would have been no behaviour change in the channel creation logic (compared to old functionality) i.e. the announcement says "...prefer to delete non-connected channels first. If all channels are connected, it will still delete the oldest channel"

So based on the announcement any connected channel should have been deleted/bumped if they were still connected regardless of the channel being created by another token and it still being connected.

Problem is that we have a distributed architecture where the same application (with same OAuth) can be running on different servers (e.g. Prod, Dev QA) at the same time (intentionally and non-intentionally) and because of the previous logic we had developed a functionality to detect channel bump by another token so that alerts can be sent of channels being bumped (outage). The purpose of the announcement should have been to allow us time to update this logic to the new functionality but the announcement failed to mentioned the breaking change i.e. only non-connected channels would be deleted instead it says "it will prefer to delete non-connected channels first. If all channels are connected, it will still delete the oldest channel" which is definitely not the case.

Please don't get me wrong. I think this new functionality is exactly what I had expected in the first place but because this was not available (for years), we had to develop our own "Channel Bump Test" to check if channels have been bumped which eventually use to happen silently and caused data outages in our customers previously. Now the problem is that we need time to change the logic to the new functionality and this would have been the purpose of the announcement. Instead we are only finding this out after issues have happened and raised by our customers and through our own tests

Overall:

I think the new behaviour requires an explicit stop of the connected channels (which is of cause preferred) rather then the old silent bump functionality (thanks of cause 😊). Anyways I think the announcement is not entirely accurate and does not correctly mention the impact. It should be updated to say "connected channels will not be deleted" rather than "...prefer to delete non-connected channels first. If all channels are connected, it will still delete the oldest channel" because that is definitely not correct.

I would really appreciate if you could confirm the above so that it can help others that might face a similar issue and have a chance to relook at into their programs channel creation and management logic.

Thanks

Shaheem

system | 2020-12-04 00:48:33 UTC | #6

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: 9193