florian.wilde/flimmer
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 9 Wiki Activity

Chore: Update-Skript erkennt den Container-Zustand, Merkposten ergänzt #10

Merged
florian.wilde merged 1 commits from chore/update-skript-und-entwicklungshinweis into main 2026-09-01 22:13:49 +00:00
Conversation 0 Commits 1 Files Changed 2
+87 -4
florian.wilde commented 2026-09-01 22:11:49 +00:00
Owner
Copy Link
Copy Source

Zwei Kleinigkeiten ohne Issue, beide aus der Arbeit an #2, #4 und #5 entstanden.

update.sh: Rückfall auf den Container-Healthcheck

Bisher prüfte das Skript ausschließlich http://127.0.0.1:$APP_PORT/api/health. Hinter einem Reverse Proxy ist der App-Port oft gar nicht auf dem Host veröffentlicht — dann meldete das Skript nach zwei Minuten einen Fehlschlag samt Rollback-Anleitung, obwohl das Update sauber durchgelaufen war.

Schlägt die Abfrage vom Host fehl, zählt jetzt der HEALTHCHECK des Containers. Den bringt das Image bereits mit (Dockerfile:86); er fragt /api/health von innen ab und ist damit unabhängig davon, ob ein Port nach außen führt.

Im Fehlerfall nennt das Skript zusätzlich den Zustand und ordnet ihn ein:

Zustand Auskunft
kein Container Der Start ist fehlgeschlagen
starting Migrationen dauern noch — Zeit geben, Log ansehen
unhealthy Läuft, aber die Anwendung hat ein Problem — nicht der Port
ohne Healthcheck Älteres Image; nur das Log verrät mehr

Ohne diese Auskunft sah ein nicht veröffentlichter Port genauso aus wie eine abgestürzte Anwendung.

container_zustand() gibt bewusst immer 0 zurück: unter set -e dürfte die Diagnose nicht selbst abbrechen, bevor der Weg zurück ausgegeben ist.

Geprüft — die Funktion isoliert gegen echte Container, alle drei Zweige:

db (hat Healthcheck):        healthy
Container ohne Healthcheck:  ohne-healthcheck:running
gibtsnicht:                  kein-container

Dazu bash -n und die Hilfeausgabe. Den vollen Lauf habe ich hier nicht ausgelöst — der würde den Produktivstack bauen.

CLAUDE.md: drei Merkposten

  • Klickwege nie gegen npm run dev prüfen. Unter headless Chromium scheitert der HMR-Socket, dadurch hydratisiert keine Seite und kein Knopf reagiert — ohne Seitenfehler, ohne fehlgeschlagene Anfrage. Sieht aus wie ein Fehler im eigenen Code. Gegen npm run build && npm start prüfen. (Hat bei #4 spürbar Zeit gekostet.)
  • Vor npm start prüfen, ob der Port noch von einem früheren Lauf belegt ist — sonst testet man unbemerkt den alten Bau. (Bei #5 passiert.)
  • scripts/shot.mjs meldet sich nicht an: bei geschützten Seiten entsteht kommentarlos ein Bild der Anmeldemaske. (Bei #2 passiert.)

Kein Issue verknüpft — beides sind Werkzeug- und Dokumentationsänderungen, kein Produktcode. Tests und Typecheck sind davon unberührt.

Zwei Kleinigkeiten ohne Issue, beide aus der Arbeit an #2, #4 und #5 entstanden. ## `update.sh`: Rückfall auf den Container-Healthcheck Bisher prüfte das Skript ausschließlich `http://127.0.0.1:$APP_PORT/api/health`. Hinter einem Reverse Proxy ist der App-Port oft gar nicht auf dem Host veröffentlicht — dann meldete das Skript nach zwei Minuten einen Fehlschlag samt Rollback-Anleitung, obwohl das Update sauber durchgelaufen war. Schlägt die Abfrage vom Host fehl, zählt jetzt der **HEALTHCHECK des Containers**. Den bringt das Image bereits mit (`Dockerfile:86`); er fragt `/api/health` von innen ab und ist damit unabhängig davon, ob ein Port nach außen führt. Im Fehlerfall nennt das Skript zusätzlich den Zustand und ordnet ihn ein: | Zustand | Auskunft | |---|---| | kein Container | Der Start ist fehlgeschlagen | | `starting` | Migrationen dauern noch — Zeit geben, Log ansehen | | `unhealthy` | Läuft, aber die Anwendung hat ein Problem — nicht der Port | | ohne Healthcheck | Älteres Image; nur das Log verrät mehr | Ohne diese Auskunft sah ein nicht veröffentlichter Port genauso aus wie eine abgestürzte Anwendung. `container_zustand()` gibt bewusst immer `0` zurück: unter `set -e` dürfte die Diagnose nicht selbst abbrechen, bevor der Weg zurück ausgegeben ist. **Geprüft** — die Funktion isoliert gegen echte Container, alle drei Zweige: ``` db (hat Healthcheck): healthy Container ohne Healthcheck: ohne-healthcheck:running gibtsnicht: kein-container ``` Dazu `bash -n` und die Hilfeausgabe. Den vollen Lauf habe ich hier nicht ausgelöst — der würde den Produktivstack bauen. ## `CLAUDE.md`: drei Merkposten - **Klickwege nie gegen `npm run dev` prüfen.** Unter headless Chromium scheitert der HMR-Socket, dadurch hydratisiert keine Seite und kein Knopf reagiert — ohne Seitenfehler, ohne fehlgeschlagene Anfrage. Sieht aus wie ein Fehler im eigenen Code. Gegen `npm run build && npm start` prüfen. (Hat bei #4 spürbar Zeit gekostet.) - Vor `npm start` prüfen, ob der Port noch von einem früheren Lauf belegt ist — sonst testet man unbemerkt den alten Bau. (Bei #5 passiert.) - `scripts/shot.mjs` meldet sich **nicht** an: bei geschützten Seiten entsteht kommentarlos ein Bild der Anmeldemaske. (Bei #2 passiert.) Kein Issue verknüpft — beides sind Werkzeug- und Dokumentationsänderungen, kein Produktcode. Tests und Typecheck sind davon unberührt.
florian.wilde added 1 commit 2026-09-01 22:11:50 +00:00
chore: Update-Skript erkennt Container-Zustand, Merkposten ergaenzt
CI / pruefen (pull_request) Canceled after 0s
Details
39098cd201 
Das Update-Skript prüfte allein http://127.0.0.1:APP_PORT/api/health. Hinter
einem Reverse Proxy ist der App-Port oft gar nicht auf dem Host
veröffentlicht — dann meldete das Skript nach zwei Minuten einen Fehlschlag,
obwohl das Update sauber durchgelaufen war.

Schlägt die Abfrage vom Host fehl, zählt jetzt der HEALTHCHECK des Containers.
Den bringt das Image schon mit; er fragt /api/health von innen ab und ist
damit unabhängig von der Portveröffentlichung.

Im Fehlerfall nennt das Skript zusätzlich den Container-Zustand und ordnet ihn
ein: kein Container (Start fehlgeschlagen), startet noch (Migrationen dauern),
läuft aber ungesund (Fehler in der Anwendung), oder ein älteres Image ohne
Healthcheck. Ohne diese Auskunft sah ein nicht veröffentlichter Port genauso
aus wie eine abgestürzte Anwendung.

container_zustand() gibt bewusst immer 0 zurück — unter set -e dürfte die
Diagnose nicht selbst abbrechen, bevor der Weg zurück ausgegeben ist.

Dazu drei Merkposten in CLAUDE.md, die diese Sitzung Zeit gekostet haben:
Klickwege müssen gegen einen Produktionsbau geprüft werden (im
Entwicklungsmodus hydratisiert unter headless Chromium nichts, weil der
HMR-Socket scheitert — ohne jede Fehlermeldung), vor npm start den Port
prüfen, und dass scripts/shot.mjs sich nicht anmeldet.
florian.wilde merged commit 605afe556d into main 2026-09-01 22:13:49 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
blockiert
offene Rückfrage, Uhr steht
 in-arbeit
Claude arbeitet daran, Stopwatch läuft
 zu-testen
umgesetzt, PR offen, wartet auf Test
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
florian.wilde (Florian Wilde)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: florian.wilde/flimmer#10