0.48.0-beta.3

Dritte Beta zur kommenden 0.48.0. Behebt den Wartungsmodus aus
0.48.0-beta.2,
der sich einschalten ließ, aber niemanden blockiert hat.

Wartungsmodus greift jetzt wirklich

Die Sperre saß in einer Middleware, die den Zustand nicht selbst lesen konnte —
in der Edge-Runtime lädt Prisma nicht — und ihn deshalb per HTTP bei der
eigenen Route geholt hat. Im Container ging dieser Aufruf an die öffentliche
Adresse, also hinaus ins Netz und über den Reverse Proxy wieder herein. Das
funktioniert dort nicht; der Fehler lief in den Fail-Open-Zweig, und von außen
sah das aus wie „Wartung ist eben aus".

Die Edge-Runtime war nie zwingend: Eine Datei namens proxy.ts führt Next auf
Node aus. Die Sperre liest die Datenbank jetzt direkt im selben Prozess. Der
Selbstaufruf und die Auskunftsroute entfallen ersatzlos — es gibt keinen
Netzwerkweg mehr, der scheitern könnte.

Zweiter Fehler, erst im Produktions-Build sichtbar: Mit Freischalt-Cookie
kamen die öffentlichen REST-Routen (Newsletter, Feedback) durch. Für tRPC
greift der Wächter unabhängig von der Freischaltung, jene beiden hingen allein
am Proxy. Der lässt jetzt alles außer GET und HEAD mit 503 abblitzen, solange
die Wartung läuft. Die Zusage „während der Wartung landet nichts Neues in der
Datenbank" gilt damit auch für Freigeschaltete.

Neu: Antworten tragen x-maintenance: active bzw. bypass. Ohne diese
Kopfzeile sind „Wartung aus" und „Sperre greift gar nicht" von außen nicht zu
unterscheiden — genau das hat den Fehler zwei Deployments lang verdeckt.

Geprüft

Diesmal gegen einen echten Produktions-Build (next build + next start),
nicht nur gegen den Entwicklungsserver. Der Unterschied war der Punkt: Beide
oben genannten Fehler treten nur dort auf.

	anonym	mit Freischalt-Cookie
/, /termine, /kontakt, /foerderverein	503 + x-maintenance: active	200 echte Seite + x-maintenance: bypass
/api/newsletter/subscribe, /api/feedback	503	503
contact.send, registrations.create	SERVICE_UNAVAILABLE	SERVICE_UNAVAILABLE
stats.recordView	läuft durch	läuft durch
/login, /dashboard, /wartung, /settings	200	200

Der Freischaltlink ist erstmals vollständig geprüft: falsches Token 404,
richtiges Token 307 mit HttpOnly; Secure; SameSite=lax, ?token=aus löscht
das Cookie wieder. Nach dem Abschalten sind alle Seiten wieder 200.

Keine Migration

20260910160000_maintenance_state aus beta.2 bleibt unverändert — Prisma prüft
die Prüfsumme angewendeter Migrationen, eine Änderung hätte jedes weitere
Deployment scheitern lassen.

Hinweis zum Testen

Betas gehen ausschließlich auf next (pwr.lehdev.de).
next.posaunenwerk-rheinland.de hängt am Produktions-Deploy und bekommt erst
mit einer vollen Version etwas davon zu sehen.