-
Notifications
You must be signed in to change notification settings - Fork 209
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add timeout support when connecting user #3303
Add timeout support when connecting user #3303
Conversation
06fa6de
to
04e0e2a
Compare
StreamChat XCMetrics
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, just added few questions. In any case, @testableapple can start testing.
Sources/StreamChat/Workers/Background/ConnectionRecoveryHandler.swift
Outdated
Show resolved
Hide resolved
4791f04
to
6fb30b2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some risky changes here and there. Can't we limit this PR to the timeout support only? This whole reconnection thing was very fragile already, not sure if we should do all these changes.
@martinmitrevski All changes are required to pass all QA Scenarios. I tried to make the changes as minimal as possible, but even with a simple change, there was always something conflicting. As you said, this part is very fragile. This PR is already a step in making it less fragile, because it makes things simpler and more obvious. |
This reverts commit 2bb971a.
…is not connected already
6fb30b2
to
f635d07
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's merge it then. Please check the failing e2e tests first - something around the offline mode, not sure if it's connected to your changes.
Afterwards, @testableapple should do a thorough QA around reconnection and token expiry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM ✅
Just one tiny issue, discussed in slack.
Quality Gate passedIssues Measures |
@@ -379,6 +382,7 @@ public class ChatClient { | |||
userInfo: UserInfo, | |||
completion: ((Error?) -> Void)? = nil | |||
) { | |||
connectionRecoveryHandler?.start() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nuno-vieira @martinmitrevski Hello, I found that this code is causing an issue, so I'm leaving a comment.
connectGuestUser
calls logOut first. As a result, ConnectionRecoveryHandler.stop is invoked, causing the monitoring of appDidBecomeActive and appDidEnterBackground to stop. This leads to the issue where "the WebSocket does not reconnect when the app resumes from the background."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I posted issue #3338
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @masarusanjp, thanks for spotting this issue!
The actual issue is that when reconnecting, logOut should not be happening, so the logic should be changed here. Stopping the recovery handler on logout is something that we want, but it caused this unwanted side effect due to the fact that logOutFirst in guest users is not properly implemented, it seems.
🔗 Issue Links
https://stream-io.atlassian.net/browse/PBE-4780
🎯 Goal
Add support for timing out reconnection.
📝 Summary
SDK:
DemoApp:
🛠 Implementation
An alternative approach to #3302 uses a separate entity to control the timeout, independent of the exponential backoff mechanism.
It uses a separate timeout handler to timeout the reconnection logic instead of using a number of retries of the existing backoff retry mechanism. The 2 main reasons for using a separate timeout handler are the following:
RetryStrategy
, which at the moment has some flaws, described in this document: https://www.notion.so/stream-wiki/Reconnection-Problems-63eeaaab19d94d50b9922b76ebb414ab🧪 Manual Testing Notes
With timeout
Without timeout
Retest token refresh:
☑️ Contributor Checklist