Constantin LeueandClaude Sonnet 5
e5c87fba5f
Der vorherige Fix (msp_telemetry_poller.dart, addError nach 3 fehl- geschlagenen Zyklen) hat die Erkennung allein nicht repariert - aus zwei Gruenden, beide jetzt behoben: 1. telemetryProvider brach bei WLAN-Verbindungsverlust (wifiLinkStateProvider != connected) den Strom bisher mit einem stillen `return;` ab, statt ueberhaupt subscribeTelemetry() zu abonnieren. Damit blieb der Provider nach einem zuvor erfolgreichen Verbindungsaufbau unbegrenzt auf dem letzten AsyncData(...) haengen, sobald das WLAN-Netz verloren ging - komplett unabhaengig vom MSP-Poller-Fix, der in diesem Fall nie erreicht wird. Ersetzt durch eine neue WifiLinkNotConnectedException. 2. Der eigentliche Grund, warum ich das beim ersten Fix nicht bemerkt habe: Riverpod 3.x wiederholt einen fehlgeschlagenen Provider standardmaessig automatisch (ProviderContainer.defaultRetry) und haelt ihn dabei in AsyncLoading(error: ..., retrying: true) statt sofort auf AsyncError zu wechseln - AsyncValue.when()s error:-Zweig (systemMessageAutoLogProvider) feuert dafuer nicht, nur der loading:-Zweig (No-Op). Das betraf sowohl die neue WifiLinkNotConnectedException als auch das per yield* durchgereichte addError aus dem MSP-Poller - beide blieben dadurch unbegrenzt "am Wiederholen haengen", nie als AsyncError sichtbar. Mit retry: (retryCount, error) => null gezielt fuer telemetryProvider deaktiviert - die eigentliche Wiederherstellung passiert ohnehin reaktiv (ref.watch(wifiLinkStateProvider) bzw. der Poller-Takt selbst), nicht ueber Riverpods Backoff. Neuer Test in telemetry_provider_test.dart deckt jetzt die komplette Kette end-to-end ab (echter MspFlightControllerLink + LoopbackTransport + ueberschriebener wifiLinkStateProvider, keine der bisherigen Tests in system_message_log_provider_test.dart haette diesen Fehler auffangen koennen, da sie telemetryProvider selbst immer ueberschreiben statt seine eigene Generatorfunktion zu durchlaufen). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
inav
@ b8de3f78f9