From 172b863c4fe59e198a1ab4d8ec395b40778dae55 Mon Sep 17 00:00:00 2001
From: fds2610-bot <fds2610-bot@users.noreply.codeberg.org>
Date: Tue, 22 Sep 2026 22:29:40 +0200
Subject: [PATCH] Update-Sicherheit: Tests vor Dienst-Neustart, API-Banner
 uebersteht Render-Fehler

update.sh startete api/web/sync bereits neu, bevor die Testsuiten liefen - schlugen sie
danach fehl, brach das Skript per set -e ab, aber die Produktion lief bereits mit dem
fehlerhaften Stand weiter. deploy-webhook.py meldet einen solchen Abbruch nirgends aktiv,
nur still im Log - ein Update konnte so unbemerkt eine kaputte Version live schalten.

Zusaetzlich: setApiBanner(true) steht jetzt in einem eigenen finally im Demo-Fallback von
boot()/refresh() - ein Fehler beim Neuzeichnen der Szene darf nicht mehr verhindern, dass
der "API nicht erreichbar"-Banner erscheint.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 html/js/office-render.js | 12 ++++++++++--
 update.sh                | 12 +++++++++---
 2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/html/js/office-render.js b/html/js/office-render.js
index b4a77ae..7b672aa 100644
--- a/html/js/office-render.js
+++ b/html/js/office-render.js
@@ -2687,8 +2687,16 @@ async function boot() {
       setApiBanner(false);
     } catch (err) {
       console.warn("[office] Live-API nicht erreichbar, zeige Demo-Daten.", err);
-      renderOfficeScene(container);
-      setApiBanner(true);
+      // setApiBanner() steht in einem eigenen finally: renderOfficeScene() zeichnet bei jedem
+      // Refresh die komplette Szene neu und kann durch einen Fehler in noch unbekannten
+      // Datenkombinationen scheitern (siehe Issue #94 - Produktion zeigte trotz nicht
+      // erreichbarer API keinen Banner). Ohne das finally wuerde ein solcher Fehler die
+      // wichtigere Meldung "API nicht erreichbar" mit sich reissen, statt sie anzuzeigen.
+      try {
+        renderOfficeScene(container);
+      } finally {
+        setApiBanner(true);
+      }
     }
   }
 
diff --git a/update.sh b/update.sh
index d066910..5ec2ff4 100644
--- a/update.sh
+++ b/update.sh
@@ -78,9 +78,12 @@ $DOCKER_COMPOSE run --rm api composer install --no-interaction --no-progress
 log "Baue Docker-Images neu (falls Dockerfile/Abhaengigkeiten sich geaendert haben)..."
 $DOCKER_COMPOSE build
 
-log "Starte Dienste neu (api, web, sync)..."
-$DOCKER_COMPOSE up -d api web sync
-
+# Tests laufen bewusst VOR dem Neustart der Dienste, in einem temporaeren Container
+# (docker compose run --rm), der die produktiven api/web/sync-Container nicht anfasst. Liefe
+# "up -d" zuerst, wuerden fehlschlagende Tests das Skript zwar per "set -e" abbrechen, die
+# Produktion liefe aber bereits mit dem fehlerhaften Stand weiter - und deploy-webhook.py
+# meldet einen solchen Abbruch nirgends aktiv, nur still im Log. Bei einem Fehlschlag hier
+# bleiben die alten Container unveraendert im Einsatz.
 if [ "$UPDATE_RUN_TESTS" = "1" ]; then
     log "Fuehre PHPUnit-Tests (API) aus..."
     $DOCKER_COMPOSE run --rm api composer test
@@ -91,4 +94,7 @@ else
     log "UPDATE_RUN_TESTS=0 gesetzt - ueberspringe Testsuiten."
 fi
 
+log "Starte Dienste neu (api, web, sync)..."
+$DOCKER_COMPOSE up -d api web sync
+
 log "Update abgeschlossen (${UPDATE_BRANCH} @ $(git rev-parse --short HEAD))."