In der Zwischenzeit glaube ich, den Bug identifiziert zu haben.
In Gladys Assistant 4.56 habe ich eine neue Authentifizierungslogik für Websockets eingeführt, die eine schnellere Verbindung ermöglicht: ideal für einen sofortigen Zugriff auf das Dashboard auf mobilen Geräten.
Das Problem? Wenn die Instanz die Verbindung verliert, versucht sie, sich mit demselben access_token, der bei der ersten Verbindung verwendet wurde, erneut zu verbinden. Allerdings ist dieser access_token inzwischen abgelaufen und wird nicht erneuert. Ich verwende eine neue Logik, die in der socket-io-Bibliothek vorhanden ist, und hatte deren Funktionsweise bei einer Trennung nicht verstanden.
Ergebnis: Der Gladys Plus-Backend lehnt die Verbindung ab (JWT abgelaufen), und die Instanz gerät in eine endlose Reconnect-Schleife.
Das ist eine gute Lektion, und hier sind einige Verbesserungsvorschläge:
-
Erneuern des access_token bei Verlust der Verbindung, um mit einem gültigen Token neu zu starten.
-
Hinzufügen einer Verzögerung vor der erneuten Verbindung, um eine Überlastung des Servers im Falle einer endlosen Schleife zu vermeiden.
-
Verbesserung der Unit-Tests, um Szenarien des Verbindungsverlusts besser abzudecken und zu verhindern, dass dieser Bug erneut auftritt.
Entschuldigung für die Unannehmlichkeiten!
Ich halte euch auf dem Laufenden, sobald die Version 4.56.1 verfügbar ist 