I’m having issues using SendBird Javascript SDK v3.0.145 with syncmanager v1.1.23.
Has anyone experienced the same issue? Any tip on how to solve it?
I’m having issues using SendBird Javascript SDK v3.0.145 with syncmanager v1.1.23.
Has anyone experienced the same issue? Any tip on how to solve it?
Welcome to the Sendbird community. The Command received no ack
error is a network based issue where the command we sent via the SDK did not receive an ACK from the Sendbird server before its timeout.
-Tyler
@Tyler thanks for the reply… Do you know what might be causing that to happen? Would be great to know how to avoid getting that error.
Hey @jkepps,
Apologize for the delay. There is not way for us to know what is causing that from your side. Essentially its the SDK stating that it didn’t receive an acknowledgement from the Sendbird server. This is typically due to network performance on the client end.
@Tyler does that mean we’ve implemented something incorrectly? Or are you saying it’s due to a poor network connection on the end user’s device? If it’s the latter it seems like the SyncManager package should handle that a little more gracefully since there’s not much that can be done about it, no?
@jkepps, not sure if this helps at all but I was consistently getting this error when marking a channel as read for a second time. The group channel’s markAsRead
method does not return a Promise
so I assumed it was idempotent and safe to call multiple times but that is not the case. I found I had a kind of race condition that I would mark the channel as read when viewing channel messages but marking it would happena a second time accidentally before I would receive the updated channel with 0 unreadMessageCount
(the condition I was checking before marking a channel as read).
This may not be your situation but if a seemingly innocuous method like markAsRead
can cause an error to be thrown when called twice (despite being idempotent), it’s possible that other APIs behave similarly…
wow, this is great to know. seems plausible this is our issue as well. thanks for sharing @Nicholas_Gelinas. unfortunate this isn’t documented…
No, it’s not due to network performance, it’s like @Nicholas_Gelinas explained, it happens when we use markAsRead, markAsDelivered, etc twice within short time frame.
Hey @jkepps and @KobarSeptyanus, I would just like to point out that SendBird just recently released v3.0.156 of their JS SDK which introduces markAsRead(callback): Promise<void>
. Now that this method returns a Promise
(or accepts a callback), it’s possible to reliably avoid duplicate calls to markAsRead
.
This is exciting! Thanks for the update!
thanks, same for me, problem was with mark as read fired twice
React.useEffect(() => {
if (channel?.unreadMessageCount) {
markAsRead();
}
}, [markAsRead, messages, channel]);
@Nicholas_Gelinas @Stanislav_Sidorov
Thanks, guys! You guys have saved me hours of debugging!