# Server-Incident: Messaging-Ausfall — 2026-05-31

## Betroffene Nutzer
`@uta:steggi-matrix.work`, `@circuitslave:steggi-matrix.work`

## Symptome
- Uta und Circuitslave konnten in verschlüsselten DM-Räumen keine Nachrichten senden
- Nachrichten von `@todesneutron` kamen nicht an bzw. konnten nicht entschlüsselt werden
- `@jochen` (Test-Account, FluffyChat) war nicht betroffen
- Später: Element zeigt „Verbindung unterbrochen / Server offline"
- Nach Behebung: alle Chats zunächst leer (History nicht sichtbar)

---

## Ursachen (in Reihenfolge des Auftretens)

### 1. Continuwuity 0.5.8 — `room_keys/version` 500-Fehler
**Endpunkt:** `GET /_matrix/client/unstable/room_keys/version`

Continuwuity 0.5.8 crashte bei dieser Anfrage mit:
```
response error: JSON serialization failed: missing field `algorithm` at line 1 column 2
500 Internal Server Error
```

Element prüft diesen Endpunkt beim Start, bevor es verschlüsselte Nachrichten sendet.
Der 500-Fehler verhinderte den korrekten Aufbau des E2E-Zustands → Senden blockiert.

FluffyChat/Pyramid implementieren diesen Check nicht → waren nicht betroffen.

### 2. Zu viele unverifizierte Geräte bei `@todesneutron`
Durch die Pyramid-Entwicklung wurden 14 Geräte angesammelt (alte FluffyChat-,
Commet- und Pyramid-Debug-Sessions). Element von Uta/Circuitslave sah all diese
Geräte als unbekannt und konnte nicht für alle gleichzeitig verschlüsseln.

### 3. Continuwuity 0.5.9-latest — Axum Routing Panic (Folgeschaden)
Beim Update auf `latest` (0.5.9, Commit `0514491`) trat ein Panic auf:
```
thread 'conduwuit:worker' panicked at axum-0.8.9/src/routing/path_router.rs:406:22:
no route for id. This is a bug in axum.
```

Ausgelöst durch: `GET /_matrix/client/v3/user/@circuitslave:steggi-matrix.work/filter/ieOT`

Circuitslaves Element hatte nach dem ersten Neustart seinen Filter verloren und
sendete diese Anfrage in einer Schleife → Server-Worker crashte wiederholt →
Cloudflare bekam EOF → alle Clients offline.

### 4. Leere Chat-History nach Behebung
Continuwuity 0.5.9 hat die interne RocksDB-Struktur von 98 auf 100 Column Families
erweitert. Das invalidierte alle gespeicherten Sync-Token der Clients → Fresh Initial
Sync → Server schickt nur aktuelle Room-States ohne vollständige Timeline.

**Die Daten waren nicht verloren** — Pagination via `/messages` funktionierte korrekt.
Durch Hochscrollen in den Räumen wurde die History nachgeladen.

---

## Maßnahmen

| Schritt | Aktion |
|---|---|
| Diagnose | Geräteliste, Raumzustand, Server-Logs via SSH geprüft |
| Geräte aufräumen | 14 → 5 aktive Geräte bei `@todesneutron` |
| Server-Update | Wechsel auf `continuwuity:main` (Commit `1faa09b`) |
| Ergebnis | `room_keys/version` gibt gültige Antwort, Filter-Panic behoben |
| History | Nutzer scrollten in Räumen nach oben → Pagination lud History nach |

---

## Server-Infrastruktur

- **Homeserver:** Continuwuity (Conduit-Fork, Rust) via Docker
- **Compose-Datei:** `/home/steggi/matrix/docker-compose.yml`
- **Image (vorher):** `registry.gitlab.com/continuwuity/continuwuity:latest` (0.5.8 → 0.5.9)
- **Image (jetzt):** `registry.gitlab.com/continuwuity/continuwuity:main` (0.5.9, Commit `1faa09b`)
- **Tunnel:** Cloudflare (`cloudflared`)
- **Datenbank:** RocksDB unter `/home/steggi/matrix/db/`

---

## Lektionen

- `latest`-Tag vor produktivem Update testen (0.5.9-latest hatte Routing-Bug)
- Alte Geräte regelmäßig aus Element/Pyramid abmelden (verhindert E2E-Probleme)
- `continuwuity:main` ist stabiler als `continuwuity:latest`
- FluffyChat/Pyramid senden auch ohne Key-Backup-Check → können als Fallback dienen