Fix: connect() Does Not Proceed When Peer is Closed π οΈ #1053
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue Link π
Fixes #1052
Goals β½
This PR aims to fix a bug where
isConnectingremains true indefinitely, preventingconnect()from proceeding after a WebSocket peer closes.As discussed in #1052, this occurs when:
π There are alternative steps to reproduce the issue, but this is the simplest method.
In other words, step 2 can be replaced by an extended sleep duration.
Additionally, this PR now includes a fix for another related scenario where
isConnectingremains stuck when the WebSocket receives awaitingerror.Implementation Details π§
Fix for
.peerClosedIssue.peerClosedevent (introduced in #946).Fix for
.waiting(Error?)Issuewaitingstate now includes an optional error (case waiting(Error?)).isConnectingis now reset to false when awaitingerror is received.Testing β
connect()now proceeds correctly after.peerClosedand.waiting(error), allowing successful reconnections.NSLogto confirm thatisConnectingresets properly.