Stream failed to open Websocket, causing later calls to fail #402
Comments
|
Hey @rubenvereecken, Can you try upgrading your dependency to the latest version and let us know if the problem still persists? Thanks. |
|
Alright we're on it, will report back after the upgrade, might take a while. |
|
Actually that was my bad, bad communication on our part. We're testing and I'll report back when we have something conclusive. |
|
There are still some That aside, is it normal that we should catch |
|
Reconnection should be automatic, we have a retry logic just for that. I'd ask you to wait for the nndb migration to be completed so you can use the very last version. About |
|
Alright so we'll put our own user-initiated retry logic on DioErrors. The chat needs to be able to service 1000s of users so may need to put our retry on your WebSocket exceptions ourselves, or is there a rough ETA on the nddb migration yet? |
|
can you give me a quick way to reproduce this bug? I'll try doing it and come back to you with more details |
|
Not really. It happens sometimes on |
|
I can verify that this issue happens and is persistent. On a slow connections, I receive a DioError timeout (6000ms) |
|
Can we get I'm fine with writing retry logic for other methods like |
|
Can you try if changing the connect/receive timeout when instantiating the client does anything? |
|
@imtoori But.. That won't actually prevent errors. What you need is a catch-all with some infinite retry logic wrapped around it. Except if you don't want to retry if there's no connection at all (to save battery), that's up to you. I saw somewhere you already have a back-off strategy implemented. |
|
yeah we have that, I need to check how that works for the first time connect call |
|
Brilliant. Just to add, we catch quite a few DioErrors in our start-up, some we retry, others are worse (like you said bad tokens for example). A lot of them are of type if (error is DioError && error.error is SocketException) {
// ...
}Some other notable but rare connection errors of type
|
|
yeah in other API calls, for example in Maybe it's not clear, but DioErrors are not related to the websocket connection anyway, that's all another different logic |
|
Also, this error seems to be due to some null safety issue, right? |
I'm.. not sure. My colleague said he gathered some more evidence, he'll post it soon. He did say when the client isn't initialised something becomes null inside the Stream SDK.
You're absolutely right, I was thinking of API errors etc which would go through Dio. |
thanks I'm sure this will help |
|
Current version we are using 1.3.2-beta So we are trying to open up the chat from the notification which carries the cid. CONNECT_TIMEOUT Error
Followed by this
Note: |
|
I can give you some advice that may help you while I try to understand how to help you better:
|
|
|
The above snippet works real well for resolving the channel from notification. |
|
How is Stream able to claim <100ms message times when connecting the user and querying channels consistently fails (+6000ms)? This issue has delayed our rollout of chat and is giving users an unacceptable experience. |
|
we just released a @searchy2 I think your problem is not the same as this one. |
|
Can you look into the backend and run a trace for all the requests on our account that took over 6 seconds to connect and update us on what the issue is there? |
|
In the latest version there is a small fix that improves the connection time client side |
|
Now I'm a bit worried too, @imtoori improving connection time can still cause time-outs. I'd like to revisit my original question
In short: What throws, literally ever, what doesn't? |
|
I want to stress the fact that the original issue:
is related to null-safety, and it was not expected at all Regarding what throws and what doesn't: Now, we're working on defining a custom error class and wrap everything with that so that it's cleaner and more reliable; I'll have more details next week. About the connection timeout: that it's not a known issue, and it should not happen. I suggest contacting support for that to solve it more quickly, knowing the details of your stream application. That's the only way we can understand if that's a backend or a client issue. |
Describe the bug
This is a bug that happened in production so all we have are stacktraces. The problem is that
queryChannelsfailed, causing some things to get stuck. The deeper issue seems to be that Stream failed to set up its Websocket connection.Here's the Websocket error. I could pinpoint the line that triggered it on our part, it's an invocation of
client.setUser.What package are you using? What version?
stream_flutter 0.2.10What platform is it about?
To Reproduce
Steps to reproduce the behavior:
0. Open app through a notification (Firebase display message) (this might be relevant, as perhaps the environment isn't fully the same on start-up or something)
client.setUser(...)Expected behavior
For Stream to create the Websocket successfully, or at least to keep trying.
Full Stacktrace
Additional context
If this can't be resolved because it's some odd fluke and it might happen from time to time, we still want to be able to deal with it. Would it be possible to document/explain which calls are expected to throw, and what we can catch? For example, if
setUseris expected to throw, we most definitely want to catch it and put some retry logic around it, if indeed it's retryable.The text was updated successfully, but these errors were encountered: