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
isConnecting
remains 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
isConnecting
remains stuck when the WebSocket receives awaiting
error.Implementation Details π§
Fix for
.peerClosed
Issue.peerClosed
event (introduced in #946).Fix for
.waiting(Error?)
Issuewaiting
state now includes an optional error (case waiting(Error?)
).isConnecting
is now reset to false when awaiting
error is received.Testing β
connect()
now proceeds correctly after.peerClosed
and.waiting(error)
, allowing successful reconnections.NSLog
to confirm thatisConnecting
resets properly.