florian.wilde/Laufzettel
1
0
Fork 0
Code Issues 5 Pull Requests Actions 4 Packages Projects Releases 1 Wiki Activity

feat(laeufe): Live-Aktualisierung per Ereignisstrom statt Polling (#53) #60

Closed
florian.wilde wants to merge 0 commits from feat/53-sse into main
pull from: feat/53-sse
merge into: :main
Conversation 0 Commits - Files Changed -
florian.wilde commented 2026-10-05 07:36:51 +00:00
Owner
Copy Link
Copy Source

M20 aus Phase 2. Die Abarbeitungsansicht fragte alle zehn Sekunden nach dem Zustand — jetzt kommt die Änderung sofort.

Gemessen: 485 ms beim Zuschauer (am Handy 487 ms), vorher bis zu zehn Sekunden. Zwanzig offene Laschen kosten nichts mehr statt zwanzig Abfragen je zehn Sekunden.

Wie es gebaut ist

  • Das Ereignis kommt aus der Datenbank. Vier Trigger schicken NOTIFY lauf_geaendert, '<laufId>', eine LISTEN-Verbindung je Prozess hört zu, der Route Handler schiebt weiter. Aus demselben Grund, aus dem auch die Regeln dort stehen: ein Trigger sieht auch den Seed, eine Migration und die Reparatur per psql. Und NOTIFY erreicht jede Instanz der Anwendung, ohne einen zweiten Dienst wie Redis.
  • Ein Handler für beide Wege, unterschieden allein am Accept-Kopf, den EventSource von sich aus schickt. Damit ist „das Polling bleibt als Rückfall, nicht als zweite Wahrheit“ keine Absichtserklärung, sondern Bauart: dieselbe Rechteprüfung, dasselbe Lesemodell, dieselbe Nutzlast. Ein zweiter Endpunkt wäre eine zweite Stelle, an der jemand rechtErforderlich vergessen kann.
  • Die Obergrenze braucht keinen Sonderfall. Ist SSE_MAX_STROEME (200) erreicht, antwortet der Handler gewöhnlich mit JSON; EventSource meldet darauf einen Fehler und versucht es nicht wieder, also fällt der Client von sich aus auf Polling zurück.
  • Keine Verbindung aus dem Prisma-Pool. Ein Pool gibt Verbindungen zurück und verteilt sie neu; ein LISTEN darauf gilt danach für eine fremde Anfrage oder für niemanden.
  • Bei versteckter Lasche wird der Strom geschlossen, nicht bloß ignoriert — sonst belegte jede Hintergrundlasche genau die Verbindung, die die Obergrenze schützen soll.

Was das Issue falsch vorgeschlagen hatte

Es nannte Trigger auf Schrittergebnis und Lauf. laufZustand trägt aber auch die Zahl der Kommentare, und seit #52 gibt es Anhänge. Das Polling verglich alle zehn Sekunden den ganzen Stand und sah sie damit; ein Strom sieht nur, was gemeldet wird.

Mit den zwei Triggern aus dem Issue wäre der Kommentar des Kollegen nie angekommen — und niemandem wäre etwas aufgefallen, weil die Seite aussieht wie immer. Das ist derselbe Fehlertyp wie in #52: eine Zusage, die niemand prüft.

Jetzt melden vier Tabellen, laufZustand trägt anzahlAnhaenge (ein Ereignis ohne Entsprechung im Zustand löst nichts aus), und beide Tests zählen namentlich auf, was dazugehört. Gegenprobe gefahren: ohne die Trigger auf Kommentar und Anhang wird tests/lauf-ereignisse.test.ts rot.

Zwei Fehler in der Proxy-Doku, beide aus #52

  • client_max_body_size 8m bei ANHANG_MAX_MB=10: ein 10-MB-Foto wäre an nginx mit „413 Request Entity Too Large“ gescheitert, und die freundliche Meldung der Anwendung wäre nie zum Zuge gekommen. Jetzt 12m, mit dem Hinweis, dass beide Werte zusammengehören.
  • Der Kommentar am proxy_read_timeout beschrieb noch das alte Polling. Jetzt steht dort, warum der Wert nicht unter 30 s fallen darf: sonst reißt der Strom zwischen zwei Herzschlägen.

Gefunden beim Schreiben der Doku, nicht von einem Test — Dateien, die ein Dritter liest, prüft hier niemand.

Geprüft

  • pnpm lint, typecheck, format:pruefen, pruefe:doku grün
  • 1266 Vitest-Tests grün (vorher 1247), davon 18 neue in tests/lauf-ereignisse.test.ts
  • 4 Playwright-Abläufe in tests/e2e/live.spec.ts, Desktop und Handy: zwei Browser-Kontexte am selben Lauf, und für den Rückfall wird dem Zuschauer EventSource vor dem Laden weggenommen (dauert dann erwartungsgemäß ~13 s)
  • Der Herzschlag echt über 70 Sekunden gefahren, nicht nur mit verkürztem Intervall im Test: readyState blieb OPEN, ein einziges Zustands-Ereignis, kein Fehler, kein Neuaufbau

Alle fünf Akzeptanzkriterien aus docs/issues/033-sse-live.md sind damit belegt.

Closes #53

🤖 Generated with Claude Code

M20 aus Phase 2. Die Abarbeitungsansicht fragte alle zehn Sekunden nach dem Zustand — jetzt kommt die Änderung sofort. **Gemessen: 485 ms** beim Zuschauer (am Handy 487 ms), vorher bis zu zehn Sekunden. Zwanzig offene Laschen kosten nichts mehr statt zwanzig Abfragen je zehn Sekunden. ## Wie es gebaut ist - **Das Ereignis kommt aus der Datenbank.** Vier Trigger schicken `NOTIFY lauf_geaendert, '<laufId>'`, eine LISTEN-Verbindung je Prozess hört zu, der Route Handler schiebt weiter. Aus demselben Grund, aus dem auch die Regeln dort stehen: ein Trigger sieht auch den Seed, eine Migration und die Reparatur per `psql`. Und `NOTIFY` erreicht jede Instanz der Anwendung, ohne einen zweiten Dienst wie Redis. - **Ein Handler für beide Wege**, unterschieden allein am `Accept`-Kopf, den `EventSource` von sich aus schickt. Damit ist „das Polling bleibt als Rückfall, nicht als zweite Wahrheit“ keine Absichtserklärung, sondern Bauart: dieselbe Rechteprüfung, dasselbe Lesemodell, dieselbe Nutzlast. Ein zweiter Endpunkt wäre eine zweite Stelle, an der jemand `rechtErforderlich` vergessen kann. - **Die Obergrenze braucht keinen Sonderfall.** Ist `SSE_MAX_STROEME` (200) erreicht, antwortet der Handler gewöhnlich mit JSON; `EventSource` meldet darauf einen Fehler und versucht es nicht wieder, also fällt der Client von sich aus auf Polling zurück. - **Keine Verbindung aus dem Prisma-Pool.** Ein Pool gibt Verbindungen zurück und verteilt sie neu; ein `LISTEN` darauf gilt danach für eine fremde Anfrage oder für niemanden. - Bei versteckter Lasche wird der Strom **geschlossen**, nicht bloß ignoriert — sonst belegte jede Hintergrundlasche genau die Verbindung, die die Obergrenze schützen soll. ## Was das Issue falsch vorgeschlagen hatte Es nannte Trigger auf `Schrittergebnis` und `Lauf`. `laufZustand` trägt aber auch die Zahl der **Kommentare**, und seit #52 gibt es **Anhänge**. Das Polling verglich alle zehn Sekunden den ganzen Stand und sah sie damit; ein Strom sieht **nur, was gemeldet wird**. Mit den zwei Triggern aus dem Issue wäre der Kommentar des Kollegen **nie** angekommen — und niemandem wäre etwas aufgefallen, weil die Seite aussieht wie immer. Das ist derselbe Fehlertyp wie in #52: eine Zusage, die niemand prüft. Jetzt melden vier Tabellen, `laufZustand` trägt `anzahlAnhaenge` (ein Ereignis ohne Entsprechung im Zustand löst nichts aus), und beide Tests zählen namentlich auf, was dazugehört. **Gegenprobe gefahren:** ohne die Trigger auf `Kommentar` und `Anhang` wird `tests/lauf-ereignisse.test.ts` rot. ## Zwei Fehler in der Proxy-Doku, beide aus #52 - `client_max_body_size 8m` bei `ANHANG_MAX_MB=10`: ein 10-MB-Foto wäre an nginx mit „413 Request Entity Too Large“ gescheitert, und die freundliche Meldung der Anwendung wäre nie zum Zuge gekommen. Jetzt 12m, mit dem Hinweis, dass beide Werte zusammengehören. - Der Kommentar am `proxy_read_timeout` beschrieb noch das alte Polling. Jetzt steht dort, warum der Wert nicht unter 30 s fallen darf: sonst reißt der Strom zwischen zwei Herzschlägen. Gefunden beim Schreiben der Doku, nicht von einem Test — Dateien, die ein Dritter liest, prüft hier niemand. ## Geprüft - `pnpm lint`, `typecheck`, `format:pruefen`, `pruefe:doku` grün - **1266 Vitest-Tests** grün (vorher 1247), davon 18 neue in `tests/lauf-ereignisse.test.ts` - **4 Playwright-Abläufe** in `tests/e2e/live.spec.ts`, Desktop und Handy: zwei Browser-Kontexte am selben Lauf, und für den Rückfall wird dem Zuschauer `EventSource` vor dem Laden weggenommen (dauert dann erwartungsgemäß ~13 s) - **Der Herzschlag echt über 70 Sekunden gefahren**, nicht nur mit verkürztem Intervall im Test: `readyState` blieb `OPEN`, ein einziges Zustands-Ereignis, kein Fehler, kein Neuaufbau Alle fünf Akzeptanzkriterien aus `docs/issues/033-sse-live.md` sind damit belegt. Closes #53 🤖 Generated with [Claude Code](https://claude.com/claude-code)
florian.wilde added 1 commit 2026-10-05 20:50:49 +00:00
feat(laeufe): Live-Aktualisierung per Ereignisstrom statt Polling (#53)
Prüfung / pruefung (pull_request) Canceled after 0s
Details
Prüfung / e2e (pull_request) Canceled after 0s
Details
Prüfung / pruefung (push) Canceled after 0s
Details
Prüfung / e2e (push) Canceled after 0s
Details
1be73b266c 
Die Abarbeitungsansicht fragte alle zehn Sekunden nach dem Zustand. Jetzt
melden vier Datenbank-Trigger `NOTIFY lauf_geaendert, '<laufId>'`, eine
LISTEN-Verbindung je Prozess hoert zu, und der Route Handler schiebt
weiter. Gemessen: der Haken des Kollegen ist nach 485 ms beim Zuschauer
(am Handy 487 ms), vorher bis zu zehn Sekunden. Zwanzig offene Laschen
kosten nichts mehr statt zwanzig Abfragen je zehn Sekunden.

Das Ereignis kommt aus der Datenbank und nicht aus dem Dienst, aus
demselben Grund, aus dem auch die Regeln dort stehen: ein Trigger sieht
auch den Seed, eine Migration und die Reparatur per psql. Und NOTIFY
erreicht jede Instanz der Anwendung, ohne einen zweiten Dienst.

Welche Tabellen melden, haengt an dem, was `laufZustand` liefert — nicht
daran, was das Issue vorgeschlagen hat. Mit Triggern nur auf
Schrittergebnis und Lauf waere der Strom ein **Rueckschritt** gewesen:
das Polling verglich den ganzen Stand und sah deshalb auch Kommentare,
ein Strom sieht nur, was gemeldet wird. Der Kommentar des Kollegen waere
nie angekommen, und die Seite haette ausgesehen wie immer. Es melden
jetzt vier Tabellen, und `laufZustand` traegt `anzahlAnhaenge` — ein
Ereignis ohne Entsprechung im Zustand loest nichts aus.

Das Polling bleibt als Rueckfall an **derselben** Adresse, unterschieden
nur am Accept-Kopf: eine Rechtepruefung, ein Lesemodell, eine Nutzlast.
Ein zweiter Endpunkt waere eine zweite Stelle, an der jemand
rechtErforderlich vergessen kann. Bei erreichter Obergrenze antwortet
der Handler gewoehnlich mit JSON; EventSource meldet darauf einen Fehler
und versucht es nicht wieder, also faellt der Client von sich aus
zurueck — ohne Sonderfall.

Nebenbei zwei Fehler in docs/betrieb/reverse-proxy.md behoben, beide aus
#52: `client_max_body_size 8m` bei `ANHANG_MAX_MB=10` haette ein
10-MB-Foto mit 413 abgewiesen, bevor die eigene Meldung zum Zuge kommt.

Closes #53

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
florian.wilde force-pushed feat/53-sse from 4aa79c93ff to 1be73b266c 2026-10-05 20:50:49 +00:00 Compare
florian.wilde closed this pull request 2026-10-05 20:56:40 +00:00
florian.wilde deleted branch feat/53-sse 2026-10-05 20:56:40 +00:00

Pull request closed

This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
backend
Datenmodell, Services, Queries
 bug
Fehler
 docs
README, Anleitung, Devlog, Changelog
 frontend
Oberflaeche, Komponenten, Design
 infra
Docker, Compose, Proxmox, CI, Release
 phase-1
Phase 1 – MVP
 phase-2
Phase 2 – SCIM, Graph, Bausteine, Anhaenge
 phase-3
Phase 3 – PDF-Protokoll, bedingte Schritte, Freigabe
 phase-4
Phase 4 – Aktionen, Connectors, REST-API
 security
Rechte, Geheimnisse, Datenschutz
 test
Vitest, Playwright, Testdaten
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/Laufzettel#60