Repository navigation
Conversation
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: true
Comment |
This was referenced Oct 24, 2026
connect() reconnects at once after a dropped connection, returns when the server closes the connection normally, retries a handshake error such as HTTP 404 forever, and counts every disconnect over the client's lifetime toward max_reconnects. A caller cannot change any of this. Add keyword arguments to WebSocketClient. Each defaults to today's behavior: - reconnect_backoff, max_reconnect_backoff: wait before reconnecting after an open connection closes. The wait doubles with each failure in a row, up to the cap, plus up to 20% jitter; at the cap it is drawn from [cap / 1.2, cap], never below reconnect_backoff. The constructor raises ValueError if reconnect_backoff is negative or greater than max_reconnect_backoff. - reconnect_on_close: also reconnect when the server closes normally. A close() by the caller while connected still ends connect(). - max_consecutive_failures, stable_uptime: limit failures in a row. A failure is an attempt that fails, or a connection that closes before it has been open for stable_uptime seconds. max_reconnects keeps its meaning. - raise_fatal_errors: use websockets' default process_exception, which raises errors that retrying will not fix. The reconnect loop is still async for ... in websockets' connect(). connect() now also accepts process_exception, which used to raise TypeError because the client passed its own. The new attribute max_connections_reached tells whether the server sent a max_connections status during the last handshake; the processor receives the same messages as before.
chipkent
force-pushed
the
fix/ws-keep-subscriptions-on-reconnect
branch
from
October 24, 2026 14:54
4c8e194 to
1f2d987
Compare
chipkent
force-pushed
the
feat/ws-reconnect-options
branch
from
October 24, 2026 14:54
6ebec59 to
217eec5
Compare
This was referenced Oct 24, 2026
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
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.
Fixes #<issue: F2-options>
Builds on #19. Related to massive-com#818 and massive-com#935, which set today's reconnect behavior.
Defaults are unchanged. New
WebSocketClientkeyword arguments let a long-running client opt in:reconnect_backoff0.0max_reconnect_backoff120.0[cap / 1.2, cap](never belowreconnect_backoff)reconnect_on_closeFalsemax_consecutive_failuresNonestable_uptime60.0raise_fatal_errorsFalseprocess_exception, which raises e.g. HTTP 404stable_uptime.max_reconnectskeeps its meaning, and aclose()while connected still endsconnect(). Aclose()during the wait before a reconnect does not stop that reconnect; feat: add WebSocketClient.request_close() #24 makes it do so.ValueErrorifreconnect_backoffis negative or greater thanmax_reconnect_backoff.connect(process_exception=...)reaches websockets instead of raisingTypeError.max_connections_reached. The processor gets the same messages as before.async for ... in connect(...).The knowledge base says the server takes "roughly 10 to 30 seconds" to release a dropped connection.
Tests
test_reconnect_options.pypatchesrandomandasyncio.sleepinstead of timing, and checks theValueError.mock_server.pyanswers handshakes on/404/with HTTP 404.make testandmake lintpass on 3.10 and 3.14.