Skip to content

check if socket is still disconnecting and allow connect#6110

Merged
SteffenDE merged 2 commits intomainfrom
sd-issue-6103
Mar 27, 2025
Merged

check if socket is still disconnecting and allow connect#6110
SteffenDE merged 2 commits intomainfrom
sd-issue-6103

Conversation

@SteffenDE
Copy link
Copy Markdown
Contributor

@SteffenDE SteffenDE commented Mar 3, 2025

Fixes #6103.

Disclaimer: I did not test this!

@SteffenDE SteffenDE closed this Mar 19, 2025
@SteffenDE SteffenDE reopened this Mar 19, 2025
@SteffenDE SteffenDE added this to the v1.8 milestone Mar 20, 2025
@SteffenDE SteffenDE merged commit e4b88df into main Mar 27, 2025
13 of 15 checks passed
@SteffenDE SteffenDE deleted the sd-issue-6103 branch March 27, 2025 11:39
SteffenDE added a commit that referenced this pull request Mar 27, 2025
* check if socket is still disconnecting and allow connect

Fixes #6103.

* check connectClock in teardown
clarkware pushed a commit to clarkware/phoenix that referenced this pull request Apr 18, 2025
…ework#6110)

* check if socket is still disconnecting and allow connect

Fixes phoenixframework#6103.

* check connectClock in teardown
SteffenDE added a commit that referenced this pull request Feb 18, 2026
Closes #6600.
Closes #6599.

In #6110 I added a check to prevent teardown from continuing
if there was a new connection attempt in between. While this solved
the reported issue (#6103), it also means that in case someone
calls connect or disconnect in between the original teardown call
and the waitForBufferDone, we would not actually close the original
connection, leaving dangling connections.

The fix is to always use the original connection that was supposed
to be closed in teardown and the subsequent checks and only set
this.conn to null when it is still the same object.

Co-Authored-By: satoren <satoreyo@hotmail.com>
SteffenDE added a commit that referenced this pull request Feb 21, 2026
Closes #6600.
Closes #6599.

In #6110 I added a check to prevent teardown from continuing
if there was a new connection attempt in between. While this solved
the reported issue (#6103), it also means that in case someone
calls connect or disconnect in between the original teardown call
and the waitForBufferDone, we would not actually close the original
connection, leaving dangling connections.

The fix is to always use the original connection that was supposed
to be closed in teardown and the subsequent checks and only set
this.conn to null when it is still the same object.

Co-authored-by: satoren <satoreyo@hotmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Broken socket reconnection on browser forward/back navigation

1 participant