FDS2610/monitor
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update-Sicherheit: Tests vor Dienst-Neustart, API-Banner uebersteht Render-Fehler

Browse source 
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>
This commit is contained in:
fds2610-bot 2026-09-22 22:29:40 +02:00
parent 191baa767c
commit 172b863c4f
2 changed files with 19 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
html/js/office-render.js
View file

@ -2687,10 +2687,18 @@ async function boot() {
setApiBanner(false); setApiBanner(false);
} catch (err) { } catch (err) {
console.warn("[office] Live-API nicht erreichbar, zeige Demo-Daten.", err); console.warn("[office] Live-API nicht erreichbar, zeige Demo-Daten.", err);
// 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); renderOfficeScene(container);
} finally {
setApiBanner(true); setApiBanner(true);
} }
} }
}
requestSceneRefresh = refresh; requestSceneRefresh = refresh;

12
update.sh
View file

@ -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)..." log "Baue Docker-Images neu (falls Dockerfile/Abhaengigkeiten sich geaendert haben)..."
$DOCKER_COMPOSE build $DOCKER_COMPOSE build
log "Starte Dienste neu (api, web, sync)..." # Tests laufen bewusst VOR dem Neustart der Dienste, in einem temporaeren Container
$DOCKER_COMPOSE up -d api web sync # (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 if [ "$UPDATE_RUN_TESTS" = "1" ]; then
log "Fuehre PHPUnit-Tests (API) aus..." log "Fuehre PHPUnit-Tests (API) aus..."
$DOCKER_COMPOSE run --rm api composer test $DOCKER_COMPOSE run --rm api composer test
@ -91,4 +94,7 @@ else
log "UPDATE_RUN_TESTS=0 gesetzt - ueberspringe Testsuiten." log "UPDATE_RUN_TESTS=0 gesetzt - ueberspringe Testsuiten."
fi 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))." log "Update abgeschlossen (${UPDATE_BRANCH} @ $(git rev-parse --short HEAD))."