React SDK does not show new group channels

Hi @walter.rodriguez ,
Thank you very much for your swift reply. We use the App component directly, so there is no way to setup that parameter for our Desktop implementation.
In the case of our mobile adaptation, we do use the ChannelList component directly and have tested it with includeEmpty as well as you suggest, without luck.
However as far as I understand this parameter is apparently not relevant to our problem, since none of our channels are totally empty (we always send an ADMIN message when initializing the GroupChannel, for the problematic instances I have confirmed that these messages are indeed present so the channels aren’t empty).

What is weirdest is that no change has been done on our end for weeks. Last time a similar thing happened (file attachments broke suddenly), we fixed it upgrading to your latest UIKit. But there has been no official release beyond 2.3.2 AFAIS.

So we’re out of ideas to be honest.
Thanks for the support,

Admin messages will not count. For Sendbird, a channel with admin messages will be empty.

It’s correct that one needs to send show_empty URL param when interacting via the API for the channels to be returned from /my_group_channels. The UIKit SDK seems to behave differently though - which is what we use.

Please note the following observations:

  1. When using directly the higher component App from sendbird-uikit one cannot specify includeEmpty at all. And still we have until now been successfully displaying many channels that only have 1 admin message internally (see screenshot below). I suspected maybe App was passing includeEmpty to ChannelList but it does not seem to be the case in your source code AFAIU

  2. We use ChannelList in our mobile screen, and even when passing includeEmpty as you suggest the new GroupChannels are not appearing.

  3. We haven’t changed anything on our end as far as I know, it stopped working suddenly only for these new channels, the old ones appear OK even if they only have 1 ADMIN message in the conversation.

Thanks!

Screenshot of current App usage (ie. without includeEmpty param channels that have only one admin message appear successfully):

Hi @walter.rodriguez,
I tested again the ChannelList component with explicit includeEmpty and it does return the problematic channels as you mention.
So number 2) above is no longer applying if we explicitly set those parameters.

However I can guarantee 100% that at no place were we specifying includeEmpty until today and the component ChannelList was perfectly picking up channels that have only 1 ADMIN message.

Also the consequence for us is that we no longer can leverage App like we did until now, hence having to re-factor the Desktop implementation so it uses ChannelList with explicit parameters.

Are you available to have a deeper look into what changed around these components & maybe BE defaults, potentially rolling back to the previous behavior of App. Or should we jump to re-factor our integration with Sendbird?

Thanks @Toni_U for the update. I’m speaking with your AE here at Sendbird to give you a detail on this.

1 Like

Hello @walter.rodriguez
Would it be possible to enable a queries prop (or its channelListQuery sub-field) for the App component, to be propagated to ChannelList (source)?

Our implementation depends on that component heavily.

If I understand correctly, you should be able to propagate a query as needed and use it when listing a channel.

If not, please provide more details of your entire flow. Thanks!

Our implementation on Desktop has been literally as simple as:

import { App as SendbirdApp } from "sendbird-uikit";

export default function App({appId, userId}) {
  return (
    <SendbirdApp 
       appId={appId} 
       userId={userId} 
       theme={THEME} 
       useReaction={true} />
  )
}

That worked perfectly fine for all GroupChannels before (even the ones that had only 1 ADMIN message inside). Now since 3 days ago new GroupChannels that appear correctly created at Sendbird Backend are not fetched by the component. Those problematic channels also have inside its conversation only 1 ADMIN message.

Explicitly calling ChannelList with queries as you suggest makes those channels appear even though this explicit parameter was not necessary before.

<ChannelList
  queries={{
    channelListQuery: {
      includeEmpty: true
    }
  }}
  />

My question is, how can we propagate queries using directly the App component? It does not appear to be one of its props.

Thanks for clarifying. queries belongs to ChannelList.
You can check UIKit’s source code (since it’s open source)

Thanks for the quick reply, I am aware about that.

My question is: can you enable the possibility for App to accept the queries prop where it propagates it to its ChannelList child?

Also, is there any possible explanation you could think of intuitively of why App component used to work fine and now it doesn’t for such empty(1admin message only) channels?

Will check the first part of your question with our UIKit developers.

For the second part, not sure why it was not working before since this behaviour is per design in our SDK.

1 Like

Thanks! Would be fantastic since I believe our problem would be quickly fixed right away if we could propagate queries from App directly.

Hello @walter.rodriguez ,
I believe I have found a possible explanation, this is only a hypothesis but as far as I understand what you said here has not been entirely true the whole time.
If we fetch the response from

GET /my_group_channels/:channel-id

for two different channels:

  • Channel A. An old channel which React UIKit displays correctly via the App component (ie. no explicit includeEmpty)
  • Channel B. A newer channel which React UIKit does NOT display at all via the App component.

They both have 1 ADMIN ONLY message in their conversation.

We see that their lastMessage field is very different:

// Channel A <-- correctly fetched
{
    "message_survival_seconds": -1,
    "unread_message_count": 0,
    "is_distinct": false,
    "custom_type": "",
    "is_ephemeral": false,
    "cover_url": "https://static.sendbird.com/sample/cover/cover_12.jpg",
    "freeze": false,
    "created_by": null,
    "is_discoverable": false,
    "is_public": false,
    "data": "",
    "disappearing_message": {
        "message_survival_seconds": -1,
        "is_triggered_by_message_read": false
    },
    "ignore_profanity_filter": false,
    "is_super": false,
    "name": "",
    "member_count": 2,
    "created_at": 1629325548,
    "is_access_code_required": false,
    "is_broadcast": false,
    "last_message": {
        "custom_type": "",
        "mentioned_users": [],
        "updated_at": 0,
        "is_removed": false,
        "type": "ADMM",
        "message": "Messages are end-to-end encrypted. No one outside of this chat can read them",
        "data": "",
        "mention_type": "users",
        "created_at": 1629325548249,
        "channel_type": "group",
        "channel_url": "url-channel-A",
        "message_id": 1187906223
    },
    "unread_mention_count": 0,
    "sms_fallback": {
        "wait_seconds": -1,
        "exclude_user_ids": []
    },
    "joined_member_count": 2,
    "max_length_message": 5000,
    "channel_url": "channel-url-a",
    "channel": {
        "name": "",
        "member_count": 2,
        "custom_type": "",
        "channel_url": "channel-url-a",
        "created_at": 1629325548,
        "cover_url": "https://static.sendbird.com/sample/cover/cover_12.jpg",
        "max_length_message": 5000,
        "data": ""
    }
}

whereas Channel B:

// Channel B <-- not fetched by <App />
{
    "message_survival_seconds": -1,
    "unread_message_count": 0,
    "is_distinct": false,
    "custom_type": "",
    "is_ephemeral": false,
    "cover_url": "https://static.sendbird.com/sample/cover/cover_12.jpg",
    "freeze": false,
    "created_by": null,
    "is_discoverable": false,
    "is_public": false,
    "data": "",
    "disappearing_message": {
        "message_survival_seconds": -1,
        "is_triggered_by_message_read": false
    },
    "ignore_profanity_filter": false,
    "is_super": false,
    "name": "",
    "member_count": 2,
    "created_at": 1631718592,
    "is_access_code_required": false,
    "is_broadcast": false,
    "last_message": null,
    "unread_mention_count": 0,
    "sms_fallback": {
        "wait_seconds": -1,
        "exclude_user_ids": []
    },
    "joined_member_count": 2,
    "max_length_message": 5000,
    "channel_url": "channel-url-B",
    "channel": {
        "name": "",
        "member_count": 2,
        "custom_type": "",
        "channel_url": "channel-url-B",
        "created_at": 1631718592,
        "cover_url": "https://static.sendbird.com/sample/cover/cover_12.jpg",
        "max_length_message": 5000,
        "data": ""
    }
}

From here we can extract that before ADMM channels were considered a lastMessage, but that does not happen with newer channels - hence needing an explicit includeEmpty parameter. My suspicion is that something must have changed at your backend which no longers flags ADMIN messages as a message; which wasn’t the case before.
Let me know if this makes sense.

Thanks @Toni_U for this detailed information.
Will update this information to our developers and get back to you.

Thanks @walter.rodriguez!
Please let me know if you need specific details (eg channel URLs etc).

We’re very focused on this problem since our whole company depends on Chat which is not usable now for new clients. So we’re waiting to see if it’s worth for us to re-implement our integration via ChannelList (worst case) or you can enable queries at App to workaround this breaking change (best case).

Hi @Toni_U,

Could you DM me your Application ID? I’d like to investigate the differences in the channel/messages while Walter talks with our Engineering team.

Done, thank you for the investigation!

Note that we are in the process of pseudo-manually sending a non-admin message to each of the affected channels since this problem is totally disruptive for our operations and need to bypass it as soon as possible.

I hope that will not affect you investigation; we just cannot afford to wait any longer for this to be operational again.

I wanted to forward here some of the messages I’m exchanging with @Tyler in case it’s helpful for other Sendbird team members.

This is our snippet to send the ADMM message

const apiSendMessage = async (
  channelId: string,
  userId: string,
  messageBody: string,
  messageType: string,
): Promise<void> => {
  const payload = {
    message_type: messageType,
    user_id: userId,
    message: messageBody,
    is_silent: messageType === "ADMM" ? true : false,
  };

  const headers: Headers = new Headers();
  headers.set("Api-Token", process.env.SENDBIRD_API_TOKEN ?? "");

  const response = await fetch(`${apiUrl}/group_channels/${channelId}/messages`, {
    method: "post",
    headers,
    body: JSON.stringify(payload),
  });
  const { error, message } = await response.json();

  if (error) {
    throw new Error(`Sendbird error: ${message}`);
  }

  return;
};

Which we always call in the case of the channel’s first message as:

  const messageBody =
    "Messages are end-to-end encrypted. No one outside of this chat can read them";
  return apiSendMessage(channelUrl, "", messageBody, "ADMM")

My question stemming from the snippet and potentially helpful for you to debug this is:
Can the is_silent param have an impact on last_message GET /channels/channel-id response field? It’s still an ADMM type of message but could be helpful for debugging.

Moving our conversation back to public view,

The is_silent is most definitely the cause of this. Here is a snippet from our docs about is_silent :

Determines whether to send a message without updating some of the channel properties. If a message is sent in a channel, with this property set to true , the channel’s last_message is updated only for the sender while its unread_message_count remains unchanged for all channel members. Also, the message doesn’t send a push notification to message receivers. If the message is sent to a hidden channel, the channel still remains hidden. (Default: false )

You can see that when you pass is_silent as true, the last_message is not updated for anyone but the sender. As most ADMM messages do not have a sender, its not updated for most people.

Was is_silent recently added , around the time you started seeing these issues?