A couple of issues with the dashboard and API not returning a user and his channels.
On the Sendbird dashboard, a user with the user_id, “TEAM#MEMBER#2022-02-17T09:06:13.575Z#af322206-3dac-44b5-b7b3-0a02445eaf70”, is listed on the Users tab. However, when you search for this user_id, there are no results.
GET https://api-{application_id}.sendbird.com/v3/users/{user_id}/my_group_channels returns an empty channels array, even though the user is a member of a channel. Using GET https://api-{application_id}.sendbird.com/v3/group_channels and passing the user_id in members_include_in successfully returns the channel. Is there any reason why the former does not return the channel whereas the latter does?
To be clear, other User-related APIs such as deleting the user works as expected. Therefore, this user does indeed exist. So, for some reason, some APIs fail to return the user and his channels.
Hi @HTC - thanks for bringing these issues to our attention. Please allow us some time to internalize it, and we will get back to you with the updates.
The user IDs that you are generating contain special characters that need to be encoded in order for the search to work. That encoded value does not exist in the database, so it is not returning results. Could you please remove the timestamp from the user ID and try using only the UUID?
GET https://api-{application_id}.sendbird.com/v3/users/{user_id}/my_group_channels returns an empty channels array, even though the user is a member of a channel. Using GET https://api-{application_id}.sendbird.com/v3/group_channels and passing the user_id in members_include_in successfully returns the channel. Is there any reason why the former does not return the channel whereas the latter does?
The channel that the user TEAM#MEMBER#2022-02-17T09:06:13.575Z#af322206-3dac-44b5-b7b3-0a02445eaf70 was joined to is empty. In order to return empty channels using https://api-{application_id}.sendbird.com/v3/users/{user_id}/my_group_channels you must also include the parameter show_empty=true when you make your request. Otherwise it will only return channels that contain messages.
The search works after removing the timestamp and other special characters like # from our userIDs. However, the timestamp and # characters we’re using as our Sendbird userIDs are actually primary keys in our database. We need them for sorting purposes.
Encoding the above userID with the timestamp and # characters work when using the Platform API. The issue is with searching these userIDs in the dashboard. Does the search function in the dashboard encode the userID searched? If not, could that be the issue? If yes, the user should show up in results, but currently it doesn’t.
I also tried searching the encoded userID, but the user still doesn’t show up in results.
The issue is the search is performing URL encoding of those characters when the Dashboard performs a search. The encoded value does not exist in our database which is why the results do not show up.
If you need to store those values on the Sendbird user, I recommend looking at the metadata object and storing them there. You can use the metadata field to store custom information on the Sendbird user for sorting purposes. Your userID should be something like a UUID without special characters.
Though, what I still don’t understand is if we url-encode the above user_id ourselves and pass the url-encoded value in the GET https://api-{application_id}.sendbird.com/v3/users/{user_id} request, the user is actually returned.
For reference, after we url-encode the user_id, the value becomes: TEAM%23MEMBER%232022-02-17T09%3A06%3A13.575Z%23af322206-3dac-44b5-b7b3-0a02445eaf70. This is the value we’re passing to the request.
However, as you described, when the url encoding is being performed by the search function in the dashboard, it fails to find the user in the database. Why does the search function in the dashboard url-encode the user_id in such a way that existing users can’t be found in the database?
Both the Dashboard search and the API are encoding your user “TEAM#MEMBER#2022-02-17T09:06:13.575Z#af322206-3dac-44b5-b7b3-0a02445eaf70” to the same string.
I have reported the Dashboard search behavior to our engineering team to investigate further.
