You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit was created on GitHub.com and signed with GitHub’s verified signature.
Fixed StompClient.connect() never returning while the cloud is unreachable: a failed attempt awaited reconnect(), which slept and called connect() again, so every retry nested inside the caller's own await instead of running behind it. A caller that connects during its start-up - bluetti-home-assistant awaits this inside async_setup_entry - then stayed in start-up for the whole outage: the config entry sat on "initialising" for three hours, with no reload offered in its menu and nothing but a Home Assistant restart to clear it (bluetti-community/bluetti-home-assistant#65). connect() now makes a single attempt and schedules the retry loop in the background, and reconnect() loops instead of recursing, so the stack no longer grows by a frame per attempt either.
Fixed a socket leak on the failing side of that loop: ws_connect() can succeed and the CONNECT frame still fail, which left that socket open with nothing left to close it - one per failed attempt, until the session's connection pool had no free slot and every new connection waited for one and timed out instead. That is the _wait_for_available_connection timeout in the same report, and the reason each retry took five minutes rather than the thirty seconds its backoff asked for. Every attempt now closes whatever the previous one left behind, on both paths.
reconnect_delay is reset once a connection succeeds, so the backoff is per outage rather than cumulative: without it, every later reconnect started at whatever delay the last outage had grown it to, up to max_reconnect_delay.
disconnect() now cancels a pending reconnect task as well as the receive and heartbeat ones.