Conversation
The client never sends anything proactively (STOMP client heartbeats are 0), so a half-open socket after sleep or a network blip was invisible to it: sends failed without triggering a reconnect and the single reconnect attempt had a 3s timeout and no retry. - run_forever(ping_interval=30, ping_timeout=10) so dead sockets are detected within ~40s - replace the one-shot sleep/connect in _on_close with a backoff loop (10s to 60s) guarded by a lock; disconnect() wakes it via an Event - a send() failing with WebSocketException/OSError closes the socket so the on_close path reconnects; connect timeout closes its leaked thread - RotatingFileHandler in append mode and INFO-level lifecycle logging so the next failure is diagnosable
websocket-client already logs "Websocket connected" at INFO on its own thread when the socket opens; the app's line 250ms later used the identical phrase, which reads as a double connect in the log. It isn't: one connection, one subscription.
The connect-timeout path called ws.close(), which sets self.sock=None while that attempt's run_forever thread is still live; the thread then dereferences self.sock.sock and logs a spurious "'NoneType' object has no attribute 'sock'". Detaching on_close is enough to stop the timed-out attempt from driving a reconnect.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Clipboard sync between my Linux and macOS clients regularly stops silently; the server shows 96 of 101 websocket sessions ending in "transport error" with zero clean disconnects, while the client keeps believing it's connected.
The client never sends anything proactively (STOMP client heartbeats are
0), so a half-open socket after sleep or a Wi-Fi blip is invisible to it, a failed send doesn't trigger a reconnect, and the one reconnect it attempts has a 3s timeout and no retry.This PR:
run_forever(ping_interval=30, ping_timeout=10).sleep(10); connect()in_on_closewith a reconnect loop that backs off 10s, 20s, 40s then 60s until connected or explicitly disconnected, guarded by a non-blockingLockso a dying zombie socket can't start a second loop.disconnect()sets athreading.Eventthat breaks a sleeping backoff wait immediately, andconnect()returns early whendisconnectedso a pending auto-reconnect can't undo a user's Disconnect.send()that fails with aWebSocketException/OSErrornow closes the socket so the existing on_close path reconnects, instead of just logging "Failed to send data" and staying stuck; a connect timeout detaches its timed-out attempt so it can't drive a reconnect.RotatingFileHandler(1MB x 3) and logs the connection lifecycle at INFO. It was truncated on every launch and logged nothing about lost/reconnected, so none of this was diagnosable after the fact.