Fix #44: Speicherfehler erklären und die Ablage von selbst prüfen #52

2026-09-01T14:31:43Z

florian.wilde commented

2026-09-01 14:31:43 +00:00

Closes #44

Verständliche Meldungen

src/lib/speicher/fehler.ts übersetzt die bekannten Fälle:

Fehler	Was jetzt dasteht
`NoSuchBucket`	Ablagebereich fehlt, Verweis auf Schritt 6
`NotImplemented` (SSE)	Speicher kann die Verschlüsselung nicht, `S3_SSE` herausnehmen
`AccessDenied` u. Ä.	Zugangsdaten abgelehnt, Namen der Variablen genannt
Netzfehler	Speicher antwortet nicht, Eingaben gehen nicht verloren

Durchgereicht wird nichts. Fremde Fehlertexte tragen Hostnamen, Eimernamen und Anfragekennungen — das gehört ins Log, nicht auf den Bildschirm. Ein Test prüft ausdrücklich, dass keines davon in der Meldung landet. Unbekannte Fehler bleiben bei der allgemeinen Meldung.

Bereitschaftsprüfung

Schreibt eine winzige Datei, liest sie zurück, räumt sie weg — beantwortet damit erreichbar, Ablagebereich vorhanden und Schreibrecht auf einmal. Ergebnis in /api/gesundheit und als Zeile im Log.

{"status":"bereit","version":"1.11.1","speicher":{"status":"bereit","treiber":"s3"}}

Zwei Entscheidungen, die Erklärung brauchen

Nicht über instrumentation.ts. Der naheliegende Starthaken wird auch für die Edge-Laufzeit gebündelt, und über die Treiber kommt node:path in ein Bündel, in dem es das nicht gibt — der Build schlägt fehl. Das war ausprobiert, nicht vermutet. Die Prüfung hängt deshalb an der Gesundheitsabfrage, die der Healthcheck ab 40 s nach dem Start ohnehin alle 30 s aufruft. Eine Schonfrist von fünf Minuten verhindert, dass dabei ständig Probedateien entstehen; gemeldet wird nur bei einer Änderung.

Ein gestörter Speicher führt nicht zu 503. Sonst startete der Healthcheck den Behälter neu und machte die ganze Akte unerreichbar — wegen eines Teils, den ein Neustart nicht repariert. Fristen, Buchungen und Stammdaten funktionieren ohne Ablage weiter.

Geprüft

760 Unit-Tests, tsc, Lint und ein vollständiger Produktions-Build. Gegen drei Mutationen: NotImplemented ohne Textprüfung · alte Reihenfolge bei der Codeermittlung · Erklärung nicht benutzt — jede wird rot.

Beim Testschreiben fiel ein eigener Fehler auf: Die Codeermittlung las name vor code, und bei einem Node-Netzwerkfehler steht dort 'Error' — der echte Code wäre nie erreicht worden.

Closes #44 ## Verständliche Meldungen `src/lib/speicher/fehler.ts` übersetzt die bekannten Fälle: | Fehler | Was jetzt dasteht | |---|---| | `NoSuchBucket` | Ablagebereich fehlt, Verweis auf Schritt 6 | | `NotImplemented` (SSE) | Speicher kann die Verschlüsselung nicht, `S3_SSE` herausnehmen | | `AccessDenied` u. Ä. | Zugangsdaten abgelehnt, Namen der Variablen genannt | | Netzfehler | Speicher antwortet nicht, Eingaben gehen nicht verloren | **Durchgereicht wird nichts.** Fremde Fehlertexte tragen Hostnamen, Eimernamen und Anfragekennungen — das gehört ins Log, nicht auf den Bildschirm. Ein Test prüft ausdrücklich, dass keines davon in der Meldung landet. Unbekannte Fehler bleiben bei der allgemeinen Meldung. ## Bereitschaftsprüfung Schreibt eine winzige Datei, liest sie zurück, räumt sie weg — beantwortet damit erreichbar, Ablagebereich vorhanden und Schreibrecht auf einmal. Ergebnis in `/api/gesundheit` und als Zeile im Log. ```json {"status":"bereit","version":"1.11.1","speicher":{"status":"bereit","treiber":"s3"}} ``` ## Zwei Entscheidungen, die Erklärung brauchen **Nicht über `instrumentation.ts`.** Der naheliegende Starthaken wird auch für die Edge-Laufzeit gebündelt, und über die Treiber kommt `node:path` in ein Bündel, in dem es das nicht gibt — der Build schlägt fehl. Das war ausprobiert, nicht vermutet. Die Prüfung hängt deshalb an der Gesundheitsabfrage, die der Healthcheck ab 40 s nach dem Start ohnehin alle 30 s aufruft. Eine Schonfrist von fünf Minuten verhindert, dass dabei ständig Probedateien entstehen; gemeldet wird nur bei einer Änderung. **Ein gestörter Speicher führt nicht zu 503.** Sonst startete der Healthcheck den Behälter neu und machte die ganze Akte unerreichbar — wegen eines Teils, den ein Neustart nicht repariert. Fristen, Buchungen und Stammdaten funktionieren ohne Ablage weiter. ## Geprüft **760 Unit-Tests**, `tsc`, Lint und ein vollständiger Produktions-Build. Gegen drei Mutationen: `NotImplemented` ohne Textprüfung · alte Reihenfolge bei der Codeermittlung · Erklärung nicht benutzt — jede wird rot. Beim Testschreiben fiel ein eigener Fehler auf: Die Codeermittlung las `name` vor `code`, und bei einem Node-Netzwerkfehler steht dort `'Error'` — der echte Code wäre nie erreicht worden.

florian.wilde added 1 commit 2026-09-01 14:31:43 +00:00

Speicherfehler erklaeren und die Ablage von selbst pruefen 92c78a92ff

Beim Ablegen eines Schreibens stand in der Oberflaeche "Das Schreiben
konnte nicht abgelegt werden." Bei einer Fehlersuche am 31.08.2026 lagen
hinter genau diesem Satz nacheinander DREI verschiedene Ursachen: ein
fehlender Ablagebereich, ein Endpunkt, der auf einen fremden Anbieter
zeigte, und eine Verschluesselung, die der Speicher nicht anbietet. Ohne
Zugang zum Serverlog waere die Suche aussichtslos gewesen.

Jetzt uebersetzt src/lib/speicher/fehler.ts die bekannten Faelle in
Saetze, die sagen, was zu tun ist - fehlender Ablagebereich mit Verweis
auf Schritt 6 der Installation, abgelehnte Zugangsdaten mit den Namen der
beiden Variablen, nicht unterstuetzte Verschluesselung mit dem Hinweis auf
S3_SSE, und nicht erreichbarer Speicher mit der Zusicherung, dass die
Eingaben bleiben.

Durchgereicht wird dabei nichts. Fremde Fehlertexte tragen Hostnamen,
Eimernamen und Anfragekennungen - das gehoert ins Log, nicht auf den
Bildschirm eines Betreuers. Uebersetzt werden nur die bekannten Faelle;
alles andere bleibt bei der allgemeinen Meldung.

Dazu eine Bereitschaftspruefung: Sie schreibt eine winzige Datei, liest
sie zurueck und raeumt sie weg - und beantwortet damit erreichbar,
Ablagebereich vorhanden und Schreibrecht auf einmal. Das Ergebnis steht in
/api/gesundheit und als Zeile im Log.

## Warum nicht instrumentation.ts

Der naheliegende Ort waere der Starthaken von Next. Der wird aber auch
fuer die Edge-Laufzeit gebuendelt, und ueber die Treiber kaeme node:path
in ein Buendel, in dem es das nicht gibt - der Build schlaegt fehl. Das
war ausprobiert, nicht vermutet.

Die Pruefung haengt deshalb an der Gesundheitsabfrage. Der Healthcheck
ruft sie ab 40 Sekunden nach dem Start alle 30 Sekunden auf; die erste
Pruefung passiert also von selbst kurz nach dem Hochfahren. Eine
Schonfrist von fuenf Minuten verhindert, dass dabei alle 30 Sekunden eine
Probedatei in den Objektspeicher geht, und gemeldet wird nur bei einer
Aenderung.

Ein gestoerter Speicher fuehrt ausdruecklich NICHT zu 503. Sonst startete
der Healthcheck den Behaelter neu und machte die ganze Akte unerreichbar -
wegen eines Teils, den ein Neustart nicht repariert.

Gegen drei Mutationen geprueft: NotImplemented ohne Textpruefung, alte
Reihenfolge bei der Codeermittlung, Erklaerung nicht benutzt - jede wird
rot.

Refs #44

florian.wilde merged commit 53dde70f26 into main

2026-09-01 14:31:52 +00:00

florian.wilde deleted branch fix/44-speicherfehler-melden

2026-09-01 14:31:52 +00:00

florian.wilde referenced this pull request

2026-09-01 14:32:11 +00:00

Speicherfehler sagen nicht, was zu tun ist — und fallen erst beim ersten Dokument auf #44

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: florian.wilde/betreuungs-cockpit#52