Zum Inhalt

UI-Probleme nach Update

Nach einem GUI-Update wirkt die Oberfläche zerbrochen — weißer Bildschirm, alte Version, fehlende Buttons, Endlosladen. In den allermeisten Fällen ist das kein Bug im Update selbst, sondern ein Zwischenzustand oder ein zwischengespeicherter alter Frontend-Build.

„Vesana wird gestartet …"-Splash

Während der Neustart-Phase eines Updates ist die Oberfläche für kurze Zeit tatsächlich nicht erreichbar — der Container wird neu erstellt, Migrationen laufen, der Stack fährt hoch. Ein Overlay überbrückt diese Lücke bewusst mit einem „Vesana wird gestartet …"-Splash und prüft dabei gezielt, ob wirklich schon die neue Version antwortet, nicht nur irgendeine. Das verhindert einen verfrühten „Fertig"-Zustand, während im Hintergrund noch die alte Version läuft.

Das ist normal und braucht keinen Eingriff — einfach abwarten, bis der Splash von selbst verschwindet. Bei sehr großen Migrationen (viel Verlaufsdaten) kann das länger dauern als gewohnt.

Bleibt der Splash ungewöhnlich lange (mehr als ein paar Minuten) stehen: Details unter Updates → Fortschritts-Anzeige und, falls nötig, Update läuft nicht durch.

Hard-Reload zuerst probieren

Der häufigste „UI zeigt noch alte Buttons/fehlt ein Feature"-Fall nach einem erfolgreichen Update ist schlicht ein zwischengespeicherter alter Frontend-Build im Browser. Vor jeder tieferen Diagnose:

  • Chrome/Firefox/Edge: Strg+Shift+R (Windows/Linux) bzw. Cmd+Shift+R (macOS)
  • Falls das nicht reicht: Browser-Cache für die Domain komplett leeren (Entwicklertools → Anwendung/Storage → Cache leeren; oder Browser-Einstellungen → Zwischengespeicherte Bilder und Dateien)
  • Bei sehr hartnäckigen Fällen: Inkognito-/Privates Fenster öffnen und dort testen — zeigt sofort, ob es am lokalen Cache liegt

Ein normaler Reload (F5) lädt oft nur die HTML-Hülle neu, während gebündelte JS/CSS-Assets aus dem Browser-Cache bedient werden — deshalb explizit Hard-Reload, nicht nur Reload.

Nach Domain-/URL-Wechsel

Wurde kurz vor dem Problem die Server-URL geändert (siehe Server-URL nachträglich ändern), kann der Browser noch API-Aufrufe gegen die alte Adresse cachen. Auch hier hilft ein Hard-Reload; bleibt das Problem bestehen, prüfe direkt in den Entwicklertools (Netzwerk-Tab), gegen welche URL das Frontend tatsächlich Requests schickt.

Container tatsächlich neu gestartet?

Zeigt die UI nach Hard-Reload immer noch die alte Versionsnummer (sichtbar z. B. unten im Admin-Bereich oder im Update-Verlauf), ist das Update auf Container-Ebene nicht angekommen — unabhängig vom Browser. Prüfen:

cd /opt/vesana
docker compose -f docker-compose.prod.yml ps
docker compose -f docker-compose.prod.yml logs frontend --tail 100

Läuft der Frontend-Container noch mit dem alten Image, oder ist er gar nicht neu erstellt worden? Das deutet auf ein hängengebliebenes oder fehlgeschlagenes Update hin — siehe Update läuft nicht durch.

nginx zeigt eine gemischte Version

Selten: Der API-Container läuft schon auf der neuen Version, aber nginx serviert noch gecachte alte statische Assets. Ein docker compose restart nginx (bzw. beim Split-Setup: der jeweilige Reverse-Proxy) erzwingt, dass frische Assets ausgeliefert werden.

Checkliste

  1. Splash abwarten, nicht sofort als Fehler werten
  2. Hard-Reload (Strg/Cmd+Shift+R)
  3. Browser-Cache komplett leeren, ggf. Inkognito-Fenster testen
  4. Versionsnummer in der UI mit dem tatsächlichen Container-Stand vergleichen (docker compose ps, docker compose logs)
  5. Erst danach von einem echten Update-Fehler ausgehen

Anschluss