Die Umstellung von Dogi-Media merkt jetzt, wenn sie nicht durchkam

BEIM AUSLIEFERN AUFGEFALLEN, NICHT BEIM BAUEN.

Nach Neustart und `git pull` standen die zwei neuen Spalten noch nicht
in der echten Ablage -- die Umstellung laeuft erst beim ersten
angemeldeten Zugriff. Das ist in Ordnung. Beim Nachsehen, WARUM sie
noch nicht da waren, fiel aber der eigentliche Mangel auf:

`bereit = true` stand UNBEDINGT hinter der Schleife, und der Fehler des
`ALTER TABLE` daneben ging still in die Konsole. Ein einziger
misslungener Versuch -- Datei gesperrt, Platte voll -- haette die
Umstellung damit fuer immer als erledigt vermerkt. Danach scheitert
JEDE Liste an `SELECT ... m.gilt_ab`, und zwar fuer alle, mit einem 503
und dem Satz "gerade nicht verfuegbar", der nirgends sagt, woran es
liegt. Bis zum naechsten Neustart.

Jetzt wird nach der Schleife nachgezaehlt. Fehlt etwas, wird geworfen
statt notiert, und der Vermerk bleibt aus -- der naechste Aufruf
versucht es also wieder. Ein Aufruf, der mit einer klaren Meldung
scheitert, ist besser als hundert, die raetseln.

AUF EINER KOPIE DURCHGESPIELT, nicht an den echten Daten erlebt:
Sicherung der laufenden Ablage gezogen (`.backup`, integrity_check ok,
Zeilenzahlen gegen live geprueft), darauf beide ALTER ausgefuehrt. Die
vorhandene Zeile ueberlebt mit leerem Fenster, die Listenabfrage des
Servers laeuft wortgleich durch, integrity_check danach ok.

pruef-material 159/0 (von 155). Neu ist eine Gegenprobe, die den
halb-umgestellten Zustand herstellt -- genau den, der vorher
"erledigt" geheissen haette -- und eine Zeile, die die Spalten in der
laufenden Ablage nachzaehlt statt sie anzunehmen.

Co-Authored-By: Claude Opus 5 <[email protected]>

server/workspace-material.js

@@ -127,14 +127,35 @@ function tabellen() {
      Fehler, ein neues CREATE wuerde die vorhandenen Zeilen nicht
      erreichen. Also nachsehen, was da ist, und nur ergaenzen, was
      fehlt -- dieselbe Bauart wie bei den Personen-Spalten. */
+  const NOETIG = [["gilt_ab", "TEXT"], ["gilt_bis", "TEXT"]];
   const da = new Set(d.prepare("PRAGMA table_info(material)").all().map((c) => c.name));
-  for (const [spalte, form] of [["gilt_ab", "TEXT"], ["gilt_bis", "TEXT"]]) {
+  for (const [spalte, form] of NOETIG) {
     if (da.has(spalte)) continue;
     try {
       d.exec(`ALTER TABLE material ADD COLUMN ${spalte} ${form}`);
       console.log(`[material] Spalte '${spalte}' ergaenzt.`);
     } catch (f) { console.error(`[material] Spalte '${spalte}':`, f?.message); }
   }
+
+  /* NACHSEHEN, OB ES AUCH GEKLAPPT HAT -- und das ist keine Formalie.
+     Im ersten Entwurf stand `bereit = true` UNBEDINGT hinter der
+     Schleife, und das `catch` darueber schluckte den Fehler. Ein
+     einziger misslungener Versuch (Datei gesperrt, Platte voll) haette
+     die Umstellung damit fuer immer als erledigt vermerkt. Danach
+     scheitert JEDE Liste an `SELECT ... m.gilt_ab` -- fuer alle, mit
+     einem 503 und der Meldung "gerade nicht verfuegbar", die nirgends
+     sagt, woran es liegt.
+
+     Jetzt wird nachgezaehlt, der Vermerk nur bei Erfolg gesetzt (der
+     naechste Aufruf versucht es also wieder), und der Fehler
+     geworfen statt notiert: Ein Aufruf, der mit einer klaren Meldung
+     scheitert, ist besser als hundert, die raetseln. */
+  const jetzt = new Set(d.prepare("PRAGMA table_info(material)").all().map((c) => c.name));
+  const fehlend = NOETIG.map(([n]) => n).filter((n) => !jetzt.has(n));
+  if (fehlend.length) {
+    throw new Error(`[material] Umstellung unvollstaendig, es fehlt: ${fehlend.join(", ")}`
+      + " -- die Liste kann ohne diese Spalten nicht gelesen werden.");
+  }
   bereit = true;
 }