ChannellList infinite loading

// Detailed description of issue.

ChannelList getting infinite loading when I try to render the Chat App or when I try to render a custom one (using the example from here )

// If problem, please fill out the below. If question, please delete.
[UIKit Version]
// What version of the SDK are you using?

    "@sendbird/chat": "^4.10.4",
    "@sendbird/uikit-react": "^3.9.3",
    "react": "18.2.0",
    "next": "13.4.11",

[Reproduction Steps]
// Please provide reproduction steps and, if possible, code snippets.

  1. Create a SendbirdChat component:
'use client';

import SendbirdApp from '@sendbird/uikit-react/App';
import '@sendbird/uikit-react/dist/index.css';


export default function SendbirdChat() {
    return (
        <div className="h-[calc(100dvh-12rem)] w-full">
            <SendbirdApp appId={APP_ID ?? ''} userId="1" />
  1. Use dynamic for rendering the component
import { Metadata } from 'next';
import dynamic from 'next/dynamic';

export const metadata: Metadata = {
    title: 'Chats | Hiizzy',
    description: '',

const DynamicChat = dynamic(
    () => import('@/components/dashboard/chats/SendbirdChat'),
        ssr: false,

export default function Page() {
    return <DynamicChat />;

// How frequently is this issue occurring?

All the time

[Current impact]
// How is this currently impacting your implementation?

It is a blocker, because the chat does not work at all! The APP_ID is correct, and userId exists.

Can you share any insight into what occurs in your console logs and network logs of the browser? I’m not able to reproduce this.

No descriptive errors or anything.

The only thing we have is an 404 error (the redirect route and everything is set correctly)

I think the issue is connected to the user fetching. We aren’t sending the accessToken, and this should work, because the settings are set to this:

But for some reason it doesn’t…

If I pass the accessToken, then we get this:

I see, this makes sense then. If a user has an access_token generated, they MUST use the access_token. So you’re getting rejected because you’re attempting to login as the user without the access token. Can you try using a user without an access token and see if you get similar results?

I thought that to, but then I used user without generated token, exact same thing… so that’s not it

I can only reproduce this behavior when I pass in a user that requires an access_token. When I enter a user that does not require an access token or session token, this works as expected.

I tried passing this user that does not have accessToken issued, and it does not work for me:

But what I tried is to delete the user, and create it again, and now it works… I guess I’m going to have to do that for each user, but I’m really not sure why…

Do users have expiry date or something that we don’t see?

If I try any user created a month ago, like this one with id 6, I get the “Session token is invalid error”:

Users do not have any kind of expiry. It would be best to get an example user I can take a look at that is having this issue before you delete the user to fix it. Once the user is deleted, I won’t be able to investigate.

You can use the user with id 6 that I sent a SS of as an example, I haven’t deleted it yet.

I have more examples on Staging, user 1, no access token:

Still same issue:

I’ve got some new info. In our backend we have implemented the creation of a sendbird user when a user register.

And since we tried to implement the creation of a token as well, thats what was causing the issue. The session token was created, but it wasn’t added to the Sendbird user, and I think that’s the reason we couldn’t see it in the Sendbird Users Dashboard.

Removing that logic, fixed the user creation, and I will probably have to remove all the accounts and add them again.

Other than that I think that some kind of error would be good to indicate what’s wrong, because currently the only thing we see is a loading spinner.

Thank you for the help.

Ahh, I think it’s important to make a distinction between sessionTokens and accessTokens. sessionTokens are JWTs and are not saved anywhere on Sendbird’s servers and thus they wouldn’t be displayed anywhere. accessTokens however are non-expiring tokens that are stored in our database and thus they can be displayed on the Dashboard.

So I’m guessing that the implementation on the backend was wrong, and that it was clashing with sendbird’s session handler and causing the issue?

It’s not that it was clashing with a sessionHandler. It’s just that whenever a user has an accessToken or sessionToken generated, they MUST log in with that token. They can no longer login without one.

So because your backend was generating sessionTokens, they needed to be logging in with a sessionToken.

1 Like