When posting a reply to a message, either with the native chat SDK or the REST API, the reply shows up on the chat scene (an instance of SBUChannelViewController).
SBDMessageListParams.includeReplies is set to false, but it still shows up regardless.
When the chat scene is reloaded, the thread reply doesn’t show, so I suspect there is a bug in the observing part.
Hi @GoGo7,
The likely issue here is that the reply is received on the channel:didReceiveMessage event delegate and was inserted into the view. The SBDMessageListParams is only utilized for the initial pull of messages and does not play into what the event delegate receives. That would explain why the message is not showing up when you reload the channel.
I overrode both channel(_:didReceive:) and channel(_:didUpdate:) but both weren’t called.
I couldn’t investigate further into the issue caused from the REST API route, so I checked what was going on with SBUBaseChannelViewController.sendUserMessage(messageParams:).
Two places in SBUBaseChannelViewController are immediately responsible for the issue, but I can see how other parts need to be updated in order to support thread replies properly.
First, upsertMessagesInList(messages:needUpdateNewMessage:needReload:) seems to be the part that updates the local message list cache for responsiveness. (I may be wrong. I didn’t spend too much time reading the sample code…) Messages are appended to messageList regardless of whether they are replies or messages to the channel. Adding a guard message.parentMessageId == 0 resolves the issue.
Second, inside sendUserMessage(messageParams:), preSendMessages are uniformly added to SBUPendingMessageManager. The condition check leading to the code should add one more predicate: preSendMessage.parentMessageId == 0.
Regardless, this only solves the issue of the message bubble showing up. Thread info for the parent message is not updated,
I tried adding an independent instance of SBDChannelDelegate to SBDMain instead of overriding what was available in SBUChannelViewController.
When using the REST API, channel(_:didReceive:) was called like you said.
Inside the implementation of that method on SBUChannelViewController, messageListParams.belongs(to: message) is called, but I guess it’s not doing anything to filter out the thread reply even when includeReplies is set to false.
Then it goes on to call the above mentioned upsert method, which doesn’t check for parentMessageId, leading to the same bug.
@Tyler Do you guys have any plans to fix this in the near future? I’m wondering if I’ll have to use various workarounds and hacks to get this done.
@GoGo7 Hey I think belongTo method should be fixed to resolve your problem. I will ping team to handle it and will let you know ETA soon!
@Woo Sounds great. Hopefully it will fix both issues.
