From eb5442e7bf3219ae6ea74fa38b7b02160df3c617 Mon Sep 17 00:00:00 2001 From: Thore Cimbal Date: Tue, 11 Aug 2026 12:00:00 +0000 Subject: [PATCH] docs: runbook for calls failing due to a missing profiles row MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit @apo could log in and message but no call would start — the click produced zero server activity. Root cause: no Synapse profiles row, which makes every displayname write 500 in _check_profile_size (NoneType), leaves the account without a display name, and prevents the Element Call widget iframe from initialising. Documents diagnosis (open_id_tokens=0 is the tell), the cross-checked INSERT fix, and who is affected. Indexed in the troubleshooting README. --- .../CALLS-FEHLEN-PROFILE-ZEILE.md | 93 +++++++++++++++++++ docs/troubleshooting/README.md | 10 ++ 2 files changed, 103 insertions(+) create mode 100644 docs/troubleshooting/CALLS-FEHLEN-PROFILE-ZEILE.md diff --git a/docs/troubleshooting/CALLS-FEHLEN-PROFILE-ZEILE.md b/docs/troubleshooting/CALLS-FEHLEN-PROFILE-ZEILE.md new file mode 100644 index 0000000..64c31ec --- /dev/null +++ b/docs/troubleshooting/CALLS-FEHLEN-PROFILE-ZEILE.md @@ -0,0 +1,93 @@ +# Calls scheitern still, obwohl Login und Messaging laufen + +**Symptom:** Ein Nutzer kann sich anmelden und Nachrichten schreiben, aber **kein +Anruf kommt zustande**. Beim Klick auf „Anruf" passiert serverseitig *nichts* — +kein `openid/request_token`, kein `call.member`-Event, keine Fehlermeldung. Das +Element-Call-Widget-iframe bleibt leer bzw. lädt ewig. + +Zuerst live gesehen bei `@apo` am 2026-08-11 (Vor-Authentik-Konto, durch mehrere +Identitäts-Resets gegangen). + +## Grundursache + +Dem Konto fehlt seine Zeile in Synapses **`profiles`-Tabelle**. Jeder registrierte +Nutzer hat eine; Deaktivieren löscht sie, Reaktivieren legt sie **nicht** neu an. +Ein Konto ohne diese Zeile läuft für Messaging weiter, aber: + +1. `PUT /_matrix/client/v3/profile//displayname` crasht mit + **`TypeError: 'NoneType' object is not subscriptable`** in + `_check_profile_size` (`synapse/storage/databases/main/profile.py`). Die + Größenprüfung macht `txn.fetchone()` und indiziert das Ergebnis — bei fehlender + Zeile ist das `None`. Der Client meldet „Anzeigename konnte nicht gesetzt + werden". *(Synapse-Bug: der Code setzt die Zeile als immer vorhanden voraus.)* +2. Dadurch bleibt der Displayname leer — global **und** in der Raum-Mitgliedschaft. +3. Element Web baut die Element-Call-Widget-URL u. a. aus dem Displaynamen. Fehlt + er überall, initialisiert das **Widget-iframe nie** (meldet nie `ContentLoaded`, + in der Browser-Konsole als „Messaging present but not yet started" sichtbar). +4. Ohne aktives Widget wird nie ein OpenID-Token angefragt, also nie die SFU + erreicht — der ganze Call-Pfad bleibt stumm. + +## Diagnose (read-only, in dieser Reihenfolge) + +```bash +# 1) Das Alarmsignal: ein sonst aktiver Nutzer OHNE OpenID-Token. +# open_id_tokens werden nicht geprunt — wer je telefoniert hat, hat Einträge. +kubectl exec -n matrix matrix-stack-postgres-0 -c postgres -- \ + psql -U postgres -d synapse -At -c \ + "SELECT count(*) FROM open_id_tokens WHERE user_id='@NAME:axion1337.chat'" +# -> 0 bei einem aktiven Konto ist verdächtig. + +# 2) Die Bestätigung: fehlt die profiles-Zeile? +kubectl exec -n matrix matrix-stack-postgres-0 -c postgres -- \ + psql -U postgres -d synapse -At -c \ + "SELECT count(*) FROM profiles WHERE full_user_id='@NAME:axion1337.chat'" +# -> 0 = das ist die Ursache. + +# 3) Confounder ausschließen: ist der Testraum verschlüsselt? +# Wenn NICHT, ist Krypto/Cross-Signing als Ursache raus. +kubectl exec -n matrix matrix-stack-postgres-0 -c postgres -- \ + psql -U postgres -d synapse -At -c \ + "SELECT ev.type FROM current_state_events cse JOIN events ev ON ev.event_id=cse.event_id + WHERE cse.room_id='!RAUM:axion1337.chat' AND ev.type='m.room.encryption'" +``` + +Optional der harte Beleg im Log (der Displayname-500 erscheint beim Setzversuch): +```bash +kubectl logs -n matrix matrix-stack-synapse-main-0 --tail=3000 | grep -A15 ProfileFieldRestServlet +``` + +## Fix + +Die fehlende Registrierungs-Default-Zeile nachtragen. **Nur `user_id` (Localpart) +und `full_user_id` sind nötig, der Rest bleibt NULL** — an gesunden Konten +(`clark`, `calltest01`) gegengeprüft. Vorher immer die (fehlende) Zeile anzeigen, +nichts überschreiben: + +```bash +kubectl exec -n matrix matrix-stack-postgres-0 -c postgres -- \ + psql -U postgres -d synapse -c \ + "INSERT INTO profiles (user_id, full_user_id) + VALUES ('NAME','@NAME:axion1337.chat') ON CONFLICT (user_id) DO NOTHING + RETURNING *;" +``` + +Danach: der Nutzer setzt im Client seinen Anzeigenamen (funktioniert jetzt), +`open_id_tokens` füllt sich beim nächsten Call-Versuch, der Anruf läuft. + +## Verifikation + +```bash +# displayname gesetzt, open_id_tokens > 0, call.member vorhanden +kubectl exec -n matrix matrix-stack-postgres-0 -c postgres -- psql -U postgres -d synapse -At -c \ + "SELECT (SELECT displayname FROM profiles WHERE full_user_id='@NAME:axion1337.chat'), + (SELECT count(*) FROM open_id_tokens WHERE user_id='@NAME:axion1337.chat')" +``` + +## Wen es betrifft + +Nur Konten **ohne** `profiles`-Zeile — praktisch nur alte, mehrfach +zurückgesetzte/deaktivierte-und-reaktivierte Konten. Frisch über den +Einladungs-Flow provisionierte Konten bekommen den Displaynamen aus Authentiks +`{{ user.name }}`-Claim und haben die Zeile immer. Am 2026-08-11 war `@apo` der +einzige betroffene *lebende* Nutzer (`frank` hatte seine Zeile; +`crank`/`shank`/`stank` sind deaktiviert). diff --git a/docs/troubleshooting/README.md b/docs/troubleshooting/README.md index 8ddfb86..9e11e83 100644 --- a/docs/troubleshooting/README.md +++ b/docs/troubleshooting/README.md @@ -63,6 +63,15 @@ Dieser Ordner enthält detaillierte Troubleshooting- und Reparaturanleitungen f --- +### 5. **CALLS-FEHLEN-PROFILE-ZEILE.md** +**Für**: Konto kann sich anmelden und schreiben, aber **kein Anruf** kommt zustande +**Wann**: Call-Klick löst serverseitig nichts aus (kein `openid/request_token`, kein `call.member`); Anzeigename lässt sich nicht setzen +**Root Cause**: Fehlende `profiles`-Zeile in Synapse → Profil-Schreibpfad crasht (`_check_profile_size`, NoneType) → kein Displayname → Element-Call-Widget initialisiert nie +**Lösung**: Fehlende Registrierungs-Default-Zeile nachtragen (read-only Diagnose, dann ein `INSERT`) +**Status**: **Resolved (2026-08-11)** — `@apo` (Vor-Authentik-Konto nach mehreren Resets), einziger betroffener lebender Nutzer + +--- + ## 🎯 Schneller Einstieg ### Szenario 1: "Enrollment funktioniert nicht, ich weiß nicht warum" @@ -88,6 +97,7 @@ Dieser Ordner enthält detaillierte Troubleshooting- und Reparaturanleitungen f | User nur in Authentik, nicht in Synapse | Boje | `DIAGNOSTIK-AUTHENTIK-FLOW.md` | **Resolved (2026-07-27)** — identischer Root Cause wie bei Klaus (fehlende Write/Password/Login-Stages im `matrix-invitation`-Flow), behoben durch denselben Issue-#7-Fix. Nicht erneut mit Boje selbst nachgetestet, aber mit anderen Test-Usern (`clark`, `lucky`) end-to-end verifiziert - der zugrundeliegende Flow ist jetzt für jeden Nutzer korrekt. | | Einladungslink-Fehler: "kein ausstehender benutzer" | Klaus | `AUTHENTIK-CREATE-INVITATION-FLOW.md` | **Fixed (2026-07-27)** — `matrix-invitation` Flow hatte nur Invite+Prompt Stage-Bindings, beide auf `order=0`. Write/Password/Login-Stages fehlten komplett. Live gefixt + als Blueprint (`apps/authentik/authentik-blueprints.yaml`) reproduzierbar gemacht. | | OIDC-Integration unklar | General | `AUTHENTIK-FIX-TEMPLATE.md` | Reference | +| Calls scheitern still, Login/Messaging läuft | apo | `CALLS-FEHLEN-PROFILE-ZEILE.md` | **Resolved (2026-08-11)** — fehlende `profiles`-Zeile nachgetragen, an `clark`/`calltest01` gegengeprüft; open_id_tokens 0→6, Call verifiziert | ---