span-panel-api 3.0.0b8__tar.gz → 3.0.0b9__tar.gz

{span_panel_api-3.0.0b8 → span_panel_api-3.0.0b9}/CHANGELOG.md

@@ -4,6 +4,14 @@ All notable changes to this project will be documented in this file.
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [3.0.0b9]
+
+### Fixed
+
+- **The retry window for a rebooting panel is actually widened this time.** b8 taught the schema fetch to treat a `502` as "not ready yet" but shipped with the old five attempts capped at eight seconds — about twenty-three seconds against a panel observed
+  taking four minutes to come back, still answering 502 when the broker returned. The widening was written, lost to a failed edit in the same change, and shipped without it; nothing failed, because catching the 502 and giving up early looks exactly like
+  working. Now twelve attempts backing off to thirty seconds, a little over four minutes, and pinned by a test that asserts the total window outlasts the observed reboot rather than checking the constants individually.
+
 ## [3.0.0b8]
 
 ### Fixed

{span_panel_api-3.0.0b8 → span_panel_api-3.0.0b9}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: span-panel-api
-Version: 3.0.0b8
+Version: 3.0.0b9
 Summary: A client library for SPAN Panel API
 Project-URL: Homepage, https://github.com/SpanPanel/span-panel-api
 Project-URL: Issues, https://github.com/SpanPanel/span-panel-api/issues

{span_panel_api-3.0.0b8 → span_panel_api-3.0.0b9}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "span-panel-api"
-version = "3.0.0b8"
+version = "3.0.0b9"
 description = "A client library for SPAN Panel API"
 authors = [
     {name = "SpanPanel"}

{span_panel_api-3.0.0b8 → span_panel_api-3.0.0b9}/src/span_panel_api/mqtt/client.py

@@ -48,9 +48,21 @@ _CIRCUIT_NAMES_POLL_INTERVAL_S = 0.25
 # Re-reading the schema after a suspected generation change. Bounded because the
 # caller is a fire-and-forget task on a live connection, and generous enough to
 # outlast a panel that is still binding its HTTP port after a restart.
-_REDISPATCH_RETRY_ATTEMPTS = 5
+_REDISPATCH_RETRY_ATTEMPTS = 12
 _REDISPATCH_RETRY_INITIAL_S = 1.0
-_REDISPATCH_RETRY_MAX_S = 8.0
+_REDISPATCH_RETRY_MAX_S = 30.0
+"""How long to wait for the panel's HTTP endpoint after it returns on MQTT.
+
+Sized from a live firmware upgrade rather than guessed. The panel dropped MQTT at
+11:22:07 and the broker was back at 11:26:15 -- four minutes -- and its HTTP
+front end was still answering 502 at that moment. Five attempts capped at 8s
+gives up after about 23 seconds, which is not the same order of magnitude as a
+device that is still booting: catching the 502 buys nothing if the loop stops
+before the panel is ready.
+
+Twelve attempts backing off to 30s is a little over four minutes. Each one is a
+single GET, and the panel is the only thing that can end the wait.
+"""
 
 
 def _metadata_for_the_log() -> tuple[list[str], str]:

{span_panel_api-3.0.0b8 → span_panel_api-3.0.0b9}/tests/test_redispatch_on_reconnect.py

@@ -31,7 +31,12 @@ from unittest.mock import patch
 import pytest
 
 from span_panel_api.exceptions import SpanPanelConnectionError, SpanPanelServerError
-from span_panel_api.mqtt.client import _REDISPATCH_RETRY_ATTEMPTS, SpanMqttClient
+from span_panel_api.mqtt.client import (
+    _REDISPATCH_RETRY_ATTEMPTS,
+    _REDISPATCH_RETRY_INITIAL_S,
+    _REDISPATCH_RETRY_MAX_S,
+    SpanMqttClient,
+)
 from span_panel_api.mqtt.models import MqttClientConfig
 
 from conftest import SERIAL
@@ -364,3 +369,29 @@ async def test_an_unexpected_failure_leaves_a_usable_message_rather_than_a_bare_
     assert client.adapter is before
     assert "Reload the integration" in caplog.text
     assert "something nobody predicted" in caplog.text
+
+
+def test_the_retry_window_outlasts_a_real_panel_reboot() -> None:
+    """Catching the 502 buys nothing if the loop gives up before the panel is ready.
+
+    Measured rather than assumed. On a live firmware upgrade the panel dropped
+    MQTT at 11:22:07 and the broker was back at 11:26:15 — four minutes — and its
+    HTTP front end was still answering 502 at that moment, which is when this
+    loop starts.
+
+    Pinned as a total because the three constants only mean something together,
+    and because the widening was written once, lost to a failed edit, and shipped
+    without it. Nothing failed: the 502 was caught and the loop still gave up
+    after twenty-three seconds. A test on the constants is the only thing that
+    would have noticed.
+    """
+    delay = _REDISPATCH_RETRY_INITIAL_S
+    total = 0.0
+    for _ in range(_REDISPATCH_RETRY_ATTEMPTS):
+        total += delay
+        delay = min(delay * 2, _REDISPATCH_RETRY_MAX_S)
+
+    observed_reboot_s = 4 * 60
+    assert total >= observed_reboot_s, (
+        f"the retry window is {total:.0f}s, shorter than the {observed_reboot_s}s reboot " "this loop exists to wait out"
+    )