Nginx meldet keinen Fehler. Synapse läuft. Der Healthcheck ist grün. Der Client erhält sogar 200 OK. Trotzdem erscheinen keine neuen Nachrichten. Genau diese Art von unsichtbarem Stillstand steckt hinter einem technisch unscheinbaren Fix in Synapse 1.159.0.

Das stabile Release vom 18. August 2026 korrigiert die fehlende Replikation des Stroms quarantined_media, wenn ein Worker als Writer für Änderungen an Medienquarantänen eingesetzt wurde. In einer passenden Mehrprozess-Konfiguration konnte daraus mehr werden als ein Moderationsproblem: Allgemeine /sync-Anfragen konnten wiederholt leer zurückkommen und praktisch unbegrenzt festhängen.

Das ist kein belegter Totalausfall von Matrix. Es ist keine veröffentlichte Sicherheitslücke und kein Nachweis, dass jede Synapse-Installation betroffen war. Der Fall ist trotzdem wichtig, weil er die schwache Stelle vieler Betriebsmodelle offenlegt: Wir messen, ob ein Prozess lebt. Wir messen zu selten, ob die eigentliche Nutzerfunktion noch vorankommt.

Was 1.159.0 nachweislich behebt

GitHub weist Synapse 1.159.0 als stabiles, nicht vorveröffentlichtes Release aus. Der annotierte Tag ist gültig signiert. Laut Changelog wurde der quarantined_media-Replikationsstrom nicht gesendet, wenn der konfigurierte Writer für quarantined_media_changes ein Worker statt des Hauptprozesses war.

Pull Request 20085 beschreibt die Ursache: Bei Einführung des Stroms fehlte seine Registrierung in ReplicationCommandHandler._streams_to_replicate. Der betroffene Worker verschickte daher keine RDATA– oder POSITION-Nachrichten für diesen Strom. Der Fix trägt den Strom nach, erweitert die Konfigurationsvalidierung, präzisiert die Routing-Dokumentation und ergänzt einen Mehrprozess-Test.

Das Changelog ordnet den Grundfehler Synapse 1.152.0 zu. Pull Request 19764 nahm den Quarantänestrom später in den allgemeinen StreamToken auf; das Changelog führt diese Änderung unter 1.154.0rc1. Die belastbare Versionsaussage lautet deshalb: Der fehlende Replikationspfad bestand laut Projekt ab 1.152.0. Die konkret dokumentierte Wirkung auf allgemeine Sync-Warteprüfungen war ab der in 1.154.0 enthaltenen Token-Änderung möglich. Behoben ist die Kette in 1.159.0.

Daraus folgt ausdrücklich nicht, dass jede Installation von 1.152.0 bis 1.158.0 sichtbar betroffen war. Die Fehlerwirkung verlangte eine bestimmte Worker-Topologie und Writer-Zuordnung.

Wie ein gültiger Token „aus der Zukunft“ kam

Ein Matrix-Client erhält bei /sync einen Token, der den Fortschritt verschiedener interner Ströme bündelt. Kennt Worker A beim Quarantänestrom beispielsweise Position 42, kann er dem Client einen entsprechenden Token geben.

Die nächste Anfrage landet durch die Lastverteilung bei Worker B. Dieser kennt wegen des fehlenden Replikationspfads nur Position 41. Für B liegt der Client-Token in der Zukunft. Synapse wartet mit wait_for_stream_token(...) darauf, dass B den fehlenden Stand erreicht.

Doch genau das kann nicht passieren, wenn B die nötige Replikationsnachricht nie erhält. Nach einem internen Timeout von etwa zehn Sekunden liefert der Worker eine leere, formal erfolgreiche Antwort. Gerät der Client erneut an einen zurückliegenden Worker, wiederholt sich das Spiel.

Issue 20080 dokumentiert dieses Verhalten auf matrix.org: identische Sync-Tokens, leere Antworten und auffällige Zehn-Sekunden-Rückläufe. Ein Clientneustart mit frischem Sync konnte vorübergehend helfen. Das war ein Workaround, kein Server-Fix.

Ebenso wichtig ist die Grenze: Die geprüften Quellen belegen keinen dauerhaften Nachrichtenverlust. Sie belegen ausbleibenden Sync-Fortschritt und verspätete Anzeige.

Warum eine Medienfunktion den ganzen Chat bremsen konnte

Synapse versteht Medienquarantäne nicht als Löschen. Die Admin-Dokumentation beschreibt eine Markierung, durch die Medien für Nutzer unzugänglich werden; Datei und Vorschaubilder bleiben erhalten. Die API für Quarantäneänderungen arbeitet zudem ausdrücklich nach dem Best-effort-Prinzip.

Das sichtbare Symptom des Fehlers war trotzdem nicht „ein Bild lässt sich noch öffnen“, sondern „der Chat zeigt nichts Neues“. Ursache ist die gemeinsame Token-Struktur. Sobald der Quarantänestrom in den allgemeinen Fortschrittstoken eingebunden war, mussten alle Sync-Worker einen konsistenten Stand dieses Stroms kennen.

Ein fachlich kleiner Nebenstrom wurde damit Teil einer zentralen Wahrheitsprüfung. Das ist keine Besonderheit freier Software und kein Argument gegen Skalierung. Es ist eine typische Eigenschaft verteilter Systeme: Die Datenbank kann richtig sein, während einzelne Prozesse unterschiedliche Wirklichkeiten sehen.

Synapse 1.159.0 präzisiert außerdem das Routing. Quarantäne-Endpunkte müssen direkt zu einem passenden Writer geleitet werden, der zugleich das Medien-Repository ausführen kann. Wer Nginx nur auf Erreichbarkeit prüft, prüft diese fachliche Zuordnung nicht.

200 OK ist kein Funktionsnachweis

Klassisches Monitoring sieht in diesem Fall leicht gesund aus. Prozess läuft, Port offen, TLS gültig, Redis verbunden, Nginx erreicht das Backend. Der Nutzer erlebt trotzdem einen festgefahrenen Messenger.

Für einen Matrix-Homeserver braucht es deshalb mehrere Prüfebenen:

1. DNS, TLS und .well-known bestätigen Erreichbarkeit und korrekte Serverzuordnung.
2. Healthchecks bestätigen, dass Prozesse grundsätzlich antworten.
3. Funktionale Tests bestätigen Login, Raumbeitritt, lokale und föderierte Nachrichten, verschlüsselte Kommunikation und Medienzugriff.
4. Sync-Tests prüfen, ob next_batch-Tokens fortschreiten und neue Ereignisse auch über wiederholte Worker-Wechsel eintreffen.
5. Bei Mehrprozess-Betrieb müssen Replikationsstände und Timeouts sichtbar werden.

Die letzten beiden Punkte sind die Lehre aus diesem Vorfall. „Der Server antwortet“ ist eine Transportaussage. „Die Community kann kommunizieren“ ist eine Funktionsaussage.

Was Betreiber kontrolliert tun können

Zuerst muss die reale Lage festgestellt werden: Welche Synapse-Version läuft? Gibt es mehrere Worker? Ist stream_writers.quarantined_media_changes konfiguriert? Welche Prozesse bedienen /sync, welche die Quarantäne-Endpunkte? Eine Einzelprozess-Instanz ist durch die beschriebene Worker-Differenz nicht als betroffen belegt.

Vor einem Update gehört der Rückweg auf den Tisch. Zu einem vollständigen Synapse-Backup zählen mindestens PostgreSQL-Datenbank, Medien, Konfiguration und Signierschlüssel. Eine Sicherung ist erst belastbar, wenn der Wiederherstellungsweg bekannt und getestet ist.

Nach dem Update beginnt die Abnahme. Ein kontrolliertes Testkonto sollte neue Ereignisse in einem privaten Raum empfangen, wiederholte Sync-Anfragen sollten voranschreiten, und bei vorhandener Worker-Lastverteilung darf der Zustand nicht von einem einzelnen Prozess abhängen. Medienzugriff und Quarantänepfad müssen getrennt geprüft werden. Reale Access Tokens, Raum-IDs und interne Konfigurationen gehören nicht in öffentliche Fehlerberichte.

Gegenposition: Für kleine Selfhoster nur ein Großserverproblem?

Die Gegenposition ist berechtigt. Der dokumentierte Fehler traf eine skalierte Mehrprozess-Konfiguration auf matrix.org. Kleine Server mit einem einzelnen Synapse-Prozess sollten daraus keinen künstlichen Notfall ableiten. Der Fix war bereits im Release Candidate enthalten und ist jetzt stabil veröffentlicht.

Die Abgrenzung ändert aber nichts an der allgemeinen Betriebslehre. Gerade kleine Community-Projekte können sich keine stundenlangen grünen Scheinausfälle leisten. Sie brauchen nicht zwingend dieselbe Metriklandschaft wie matrix.org. Sie brauchen aber einen einfachen funktionalen Test, der zeigt, ob neue Nachrichten tatsächlich ankommen.

Bewertung: Souveränität braucht beobachtbare Wirklichkeit

Meine redaktionelle Bewertung: Freier Quellcode ist in diesem Fall ein handfester Vorteil. Fehlerbericht, Maintainer-Erklärung, Patch, Commit und Test sind öffentlich nachvollziehbar. Bei einer geschlossenen Plattform bliebe Nutzern häufig nur die Meldung „Es gibt Probleme“.

Doch Offenheit allein betreibt keinen Server. Digitale Souveränität entsteht erst, wenn eine Community Versionen kennt, Topologien dokumentiert, Backups wiederherstellen kann und echte Nutzerwege überwacht. Wer nur CPU, RAM und HTTP-Status misst, besitzt Infrastruktur, aber keine belastbare Aussage über deren Zweck.

Das Synapse-Projekt arbeitet bereits an besserer Sichtbarkeit. Pull Request 20095 soll Timeouts von wait_for_stream_token zählen. Pull Request 20097 soll pro Prozess die Position von ID-Generatoren ausgeben. Beide waren am Morgen des 19. August 2026 noch offen und nicht Teil des stabilen Tags 1.159.0. Der Fix ist veröffentlicht; die verbesserte Früherkennung ist noch Arbeit.

Fazit

Synapse 1.159.0 behebt einen eng konfigurationsabhängigen, aber real dokumentierten Worker-Replikationsfehler. Seine Wirkung zeigt, warum ein grünes Dashboard täuschen kann: Der Server antwortet, während der Chat praktisch steht.

Die richtige Reaktion ist keine pauschale Alarmmeldung. Sie ist eine saubere Prüfkette: Version und Topologie feststellen, Writer-Routing verstehen, vollständigen Rückweg sichern, kontrolliert aktualisieren und Kommunikation statt bloßer Erreichbarkeit testen.

Vor einer Veröffentlichung müssen der aktuelle stabile Synapse-Stand sowie die Pull Requests 20095 und 20097 erneut geprüft werden. Eine lokale Betroffenheit von Darknight-Coffee wurde nicht untersucht und wird nicht behauptet.

Quellen

1. Synapse Release v1.159.0: https://github.com/element-hq/synapse/releases/tag/v1.159.0
2. Synapse Changelog release-v1.159: https://github.com/element-hq/synapse/blob/release-v1.159/CHANGES.md
3. Pull Request 20085, Ursache und Fix: https://github.com/element-hq/synapse/pull/20085
4. Dateien und Mehrprozess-Test zu PR 20085: https://api.github.com/repos/element-hq/synapse/pulls/20085/files
5. Fix-Commit: https://github.com/element-hq/synapse/commit/62a4bc46203880dd5034483b0e84156d03a3a8c6
6. Issue 20080, dokumentierter /sync-Stillstand: https://github.com/element-hq/synapse/issues/20080
7. Pull Request 19558, Einführung des Quarantäneänderungsstroms: https://github.com/element-hq/synapse/pull/19558
8. Pull Request 19764, Aufnahme in StreamToken: https://github.com/element-hq/synapse/pull/19764
9. Synapse Media Admin API: https://element-hq.github.io/synapse/latest/admin_api/media_admin_api.html
10. Synapse Worker-Dokumentation: https://element-hq.github.io/synapse/latest/workers.html
11. This Week in Matrix, 14. August 2026: https://matrix.org/blog/2026/08/14/this-week-in-matrix-2026-08-14/#synapse-website
12. Offener Pull Request 20095: https://github.com/element-hq/synapse/pull/20095
13. Offener Pull Request 20097: https://github.com/element-hq/synapse/pull/20097

CTA

Wie stellt ihr fest, ob euer Matrix-Server nicht nur erreichbar ist, sondern wirklich synchronisiert? Diskussion: https://treff.darknight-coffee.eu/@carrabelloy

Podcast: https://podcast.darknight-coffee.org/pages/startseite

Blog: https://carrabelloy.darknight-coffee.org/blog/

Wenn dir das Projekt hilft: Spendenlinks sind im Blog.