From e80aac8b4a361393e9fb932b7016b58e22a89575 Mon Sep 17 00:00:00 2001 From: nexxo Date: Tue, 4 Aug 2026 10:59:26 +0200 Subject: [PATCH] =?UTF-8?q?Version=201.7.2=20=E2=80=94=20eine=20gescheiter?= =?UTF-8?q?te=20Anfrage=20ist=20kein=20Deployment?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- VERSION | 2 +- resources/js/app.js | 27 +++++++++++++++++++++++++-- 2 files changed, 26 insertions(+), 3 deletions(-) diff --git a/VERSION b/VERSION index 943f9cb..f8a696c 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -1.7.1 +1.7.2 diff --git a/resources/js/app.js b/resources/js/app.js index 5035043..8db7a30 100644 --- a/resources/js/app.js +++ b/resources/js/app.js @@ -410,8 +410,31 @@ document.addEventListener('alpine:init', () => { this.stuck = false; this.step = state.step ?? null; } catch { - // Expected while the containers are down. Keep asking: this is - // the middle of the very event being watched, not a fault. + // Eine gescheiterte Anfrage ist erst dann ein Deployment, wenn + // wir vorher WUSSTEN, dass eines läuft. + // + // Hier stand `this.wasRunning = true` ohne Bedingung. Damit + // schaltete jede fehlgeschlagene Anfrage das Vollbild-Fenster + // ein — auch eine, die nichts mit einer Aktualisierung zu tun + // hatte. Am Telefon passierte das ständig: `visibilitychange` + // prüft sofort bei jeder Rückkehr in den Vordergrund, das + // Funkmodul ist dann noch nicht wach, die Anfrage scheitert, + // und der Betreiber sah „Aktualisierung läuft" über einer + // Anwendung, die vollkommen in Ordnung war. 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. + // + // Während eines echten Deployments ist die Bedingung erfüllt: + // Der Server hat `running` gemeldet, bevor die Behälter + // heruntergingen. Genau dann soll das Fenster stehen bleiben, + // und genau dann tut es das weiterhin. + if (! this.wasRunning && ! this.serverConfirmed) { + this.schedule(); + + return; + } + this.wasRunning = true; // A deployment restart is seconds. Two minutes of nothing is