nexxo e80aac8b4a Version 1.7.2 — eine gescheiterte Anfrage ist kein Deployment ... Auf dem Telefon erschien das Vollbild-Fenster "Aktualisierung laeuft" immer wieder, obwohl nichts lief; nach einem Neuladen war es weg. Die Ursache stand im catch des Waechters: } catch { this.wasRunning = true; // ohne jede Bedingung Jede fehlgeschlagene Anfrage schaltete damit das Fenster ein — auch eine, die mit einer Aktualisierung nichts zu tun hatte. Am Telefon passierte das staendig: visibilitychange prueft sofort bei jeder Rueckkehr in den Vordergrund, das Funkmodul ist dann noch nicht wach, die Anfrage scheitert. Nach einem Neuladen war es weg, weil die Seite dann den echten Serverwert mitbrachte — was es wie einen Geist aussehen liess statt wie den Fehler, der es war. Jetzt gilt eine gescheiterte Anfrage erst dann als Deployment, wenn vorher bekannt war, dass eines laeuft (wasRunning oder serverConfirmed). Waehrend eines echten Deployments ist das erfuellt — der Server meldet running, bevor die Behaelter heruntergehen —, also bleibt das Fenster dort stehen wie bisher. 2879 Tests gruen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>		2026-08-04 10:59:26 +02:00
..
app.js	Version 1.7.2 — eine gescheiterte Anfrage ist kein Deployment	2026-08-04 10:59:26 +02:00
echo.js	chore: bootstrap CluPilot control-plane (Laravel 13, Docker stack)	2026-07-25 00:21:30 +02:00
site.js	Die Website hatte gar kein Alpine: elf x-show taten nichts, darunter der Preis-Umschalter	2026-08-01 18:13:55 +02:00
terminal.js	Terminal: das Fenster sagt jetzt selbst, ob die Bruecke laeuft	2026-08-02 22:34:32 +02:00