"User must be a member." error on live connection

Sendbird Chat API/SDK JavaScript
#1

Sendbird version: 3.0.144
Way of usage: React SPA

Overview what we are doing:

  1. For authentication we are using session tokens with day long expiration.
  2. We rely in one part of application on onTotalUnreadMessageCountUpdated user event handler. For that we connect user almost on the start.
  3. Interactive usage of sdk (for example sending messages, marking as read) is a bit deeper in the web app. To have it fully operational before connecting we are also creating SessionHandler, ChannelHandler and ConnectionHandler.
  4. Atop of that we have functionality that allows user to “archive” group chat. It can be triggered by any member of the chat, goes through our server, which uses sendbird platform API. First it freezes the channel and then deletes it.

Taking this all together: we create all handlers in the beginning and then we are connecting with sdk. It can happen that for most of the time we are only listening to the events. In meantime channels for the specific user can be removed.

Problem: We get a tons of errors which obfuscate our error log. Functionality is not affected directly, however we cannot go to production with so many false positives.

Thanks for help

"This session has expired" 400309 error on sessions >1h
#2

@TKawik,

Welcome to the Sendbird Community! In regards to the error you’re receiving, is the Users must be a member the only error you’re getting? Additionally, do you know what function is throwing this error? Is it early prior to the interactive usage or during?

-Tyler

#3

@Tyler
Thanks for the welcome. And for the insanely fast response :slight_smile:

In regards to the error you’re receiving, is the Users must be a member the only error you’re getting?

Correct.

Additionally, do you know what function is throwing this error?

Unfortunately, it’s not with the direct action from user side, but in one of the callbacks. From minified code I can see that it comes from ws.onmessage, which is used in:

case ye.CATEGORY_CHANNEL_JOIN:
case ye.CATEGORY_CHANNEL_LEAVE:
    o.getChannel(re.channelUrl, S.INTERNAL_CALL, ...)
...

My direct assumption is that when we want to listen on changes to the user channels it goes wrong, because those channels do not exist anymore. It is confirmed also based on the API requests that are made: https://api-xxx.sendbird.com/v3/sdk/group_channels/xxx?show_member=true&show_read_receipt=true&show_delivery_receipt=true
Problem is that this call is automatically done by SDK, so we do not have much control over it.

Is it early prior to the interactive usage or during?

It’s outside of interactive usage.

#4

Thank you for the information! One additional question. When you receive these errors, do you see them immediately after you setup the handlers or are you seeing it occur over time?

#5

Errors are happening later, not directly after setting up the handlers. They occur when one of the channels assigned to the user is deleted by another user. Of course if he will delete his own channel the same error will occur, however for that situation we could have a walk-around.

#6

Got it. So this is actually a known issue that our Engineering team is aware of. It has to do with the channel automatically being deleted when both users leave the chatroom.

I don’t have an ETA on when this will be fixed however, we could alter the behavior in your application to not delete the channel when both users leave. This would prevent that error from showing up when the channel is deleted.

1 Like
#7

I’ll check with our team if that is a feasible solution.

Thanks for the fast reply.

#8

@TKawik along with the users participating in the conversation you could also add a moderator from your team. By doing this, your channels won’t disappear.

Operators can join to as many channels as necessary.

Register operators:

Or you can add them when creating a group channel too.

#9

@walter.rodriguez
Maybe I didn’t emphasise it enough. Our GOAL is to delete channels with data connected to them after finished conversation.
Probably our current approach will be to split deletion into two phases: freezing channel and then removing it during user inactivity.