"Dane mogą być nieaktualne" wprowadzało w błąd — iframe pokazuje infoterminal
ALS bezpośrednio, więc jego dane są aktualne niezależnie od LuPorta. Przy
zerwanym WebSockecie pada wyłącznie nasza warstwa wykrywania alarmów i to
komunikat ma mówić. (Niuans opisany w README: karty na ekranie alarmowym przy
przerwie w trakcie alarmu mogą być nieświeże do 5 min, potem znikają.)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Dwa zgłoszenia z kiosku (2026-07-31):
1. BELKA ZASŁANIAŁA DANE ALS. Pełnoekranowy pasek u góry zajmował pas
ekranu i obcinał dane informacyjne w iframe. Zastąpiony cienką pulsującą
RAMKĄ wokół całego ekranu (pointer-events: none, niczego nie zakrywa)
plus małą plakietką w rogu. Z daleka widoczna równie dobrze.
2. WSKAŹNIK MIGAŁ zamiast świecić ciągle. disconnectedSince było resetowane
przy KAŻDEJ nieudanej próbie reconnectu, nie tylko przy przejściu
połączone->rozłączone — przy odstępie ponowień > 10 s (backoff dochodzi
do 30 s) licznik ciszy zerował się co próbę i wskaźnik cyklicznie znikał
i wracał. Teraz znacznik początku przerwy ustawiany wyłącznie przy
przejściu ze stanu połączonego.
Kontekst zgłoszenia: strona działa jeszcze przeciw STAREMU LuPortowi,
który nie ma kanału zbiorczego ani uwierzytelniania WS — połączenie pada
ciągle (oczekiwane do czasu wdrożenia; potem wstaje bez zmian), a błąd
zamieniał tę ciągłą przerwę w miganie.
Testy: scenariusz 7 próbkuje wskaźnik co 500 ms przez 90 s ciągłej awarii
i wymaga 100% aktywnych próbek — z błędem aktywnych było 51/182 (72% czasu
zgaszony; dokładnie zgłoszone "pojawia się i znika"). Fałszywy WebSocket
odrzuca teraz połączenia jak przeglądarka (onclose po nieudanej próbie),
więc długa przerwa z ponowieniami jest testowalna. 11/11 scenariuszy PASS,
mutacja poprawki wywraca scenariusz 7.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Ukrycie WYŁĄCZNIE przez display:none — element zostaje w DOM. Usunięcie go
z HTML to dokładnie ten błąd, który w starej wersji ubijał reconnect
(TypeError w onclose; README, Historia). refreshStatus() i tak ma osłonę na
brak elementu, ale osłona jest siatką bezpieczeństwa, nie zaproszeniem.
Do diagnostyki: jedna linia CSS albo style.display="block" w konsoli.
Pomarańczowy pasek offline zostaje bez zmian — pojawia się tylko przy utracie
łączności, czyli dokładnie wtedy, gdy MA przykryć nieaktualne dane.
10/10 testów przechodzi (testy sprawdzają logikę i klasy, nie widoczność
paska, więc ukrycie ich nie dotyka).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
PRZYCZYNA ZNIKAJĄCYCH ALARMÓW ZNALEZIONA — i nie była nią liczba połączeń.
Commit 7cf0634 ("hidden status-bar & machine.status") zakomentował element
#status-bar w HTML, ale refreshStatus() nadal po niego sięgał. TypeError na
null przerywał handler ws.onclose PRZED zaplanowaniem reconnectu — każda
maszyna po pierwszym zerwaniu połączenia milkła NA ZAWSZE. Restart z crona
co 2 h maskował problem, zaczynając od zera.
Czerwcowe poprawki na kiosku (timery świeżości per-maszyna, ubijanie "zombie"
połączeń, jitter) szły w dobrą stronę, ale nieświadomie POGORSZYŁY objaw:
watchdog celowo zamykał ciche połączenie, a każde zamknięcie przechodziło
przez ten sam wadliwy onclose — własna obrona uśmiercała maszynę na stałe.
Ich sedno jest zachowane w tej wersji (wykrywanie ciszy, jitter, nakładkowy
iframe z "iframe optimalization").
NOWA ARCHITEKTURA (pod nowy system LuPort):
- JEDNO połączenie na kanał zbiorczy /ws/als-data/ zamiast 35 per-maszyna;
serwer wysyła migawkę stanu wszystkich maszyn zaraz po połączeniu (dodane
w LuPort równolegle), więc trwający alarm wraca na ekran natychmiast po
reconnexie
- token ApiUser w adresie (nowy system wymaga uwierzytelnienia WS); konto
bot-als-alert-screen bez żadnych uprawnień
- reconnect z wykładniczym odstępem (1->30 s) i jitterem; odstęp wraca do
minimum dopiero po 60 s stabilnego połączenia
- watchdog ciszy > 90 s (przeglądarka nie wystawia ping/pong do JS — martwe
półotwarte połączenie inaczej wisi w nieskończoność)
- dane maszyny starsze niż 5 min znikają z ekranu; przy rozłączeniu dane NIE
są czyszczone od razu (alarm nie znika przy 3-sekundowym czknięciu sieci —
o niepewności mówi pomarańczowy pasek, migawka po reconnexie przywraca
prawdę)
- utrata łączności WIDOCZNA: pomarańczowy pasek po 10 s + przywrócony pasek
statusu; element MUSI istnieć w DOM, refreshStatus() ma mimo to osłonę
- MACHINES stało się filtrem wyświetlania; ?ws= i ?token= nadpisują
konfigurację z adresu strony
- karty przez textContent; celowo BRAK ws.onerror (po błędzie przeglądarka
i tak wywołuje onclose)
TESTY (test/testy_ekranu.py): 10 deterministycznych scenariuszy bez sieci —
skrypt wycinany z żywego HTML, WebSocket podmieniony fałszywką, wirtualny
czas Chromium. Scenariusz 6 to bezpośredni test regresji błędu reconnectu;
mutacja (usunięcie planowania reconnectu) wywraca scenariusze 6, 8 i 9.
CRON RESTARTUJĄCY CO 2 H MOŻNA USUNĄĆ — README opisuje czemu.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
sases
admin