XMPP: nick-conflict bij rejoin na reconnect niet afgehandeld — deelnemer valt stil uit de samenwerking #1416

New issue

Closed

opened 2026-08-09 18:24:19 +00:00 by brenno · 0 comments

brenno commented

2026-08-09 18:24:19 +00:00

Owner

Bevinding

lib/xmpp/xmpp_session.dart — de supervised reconnect (_reconnect, regels 535–586) roept na een geslaagde re-authenticatie onRejoin!(this) aan (regel 556) om de MUC-kamer(s) opnieuw te betreden. De reconnect-logica controleert het resultaat van onRejoin niet — na onRejoin wordt _reconnected.add(null) gevuurd (regel 557) en return-t de functie met succes.

Wat er gebeurt

Na een netwerkdrop kan de MUC-server de oude occupant nog steeds als aanwezig beschouwen (de presence-timeout is nog niet gevuurd, typisch 60–300 seconden). Als onRejoin de kamer opnieuw probeert te betreden met dezelfde nick, stuurt de server een 409 conflict error-presence. XmppMuc.join retourneert MucJoinResult.failed(MucJoinFailure.nickConflict).

Maar _reconnect negeert dit resultaat — het beschouwt de reconnect als geslaagd, vuurt _reconnected, en de transport-laag denkt dat alles weer synchroon is. In werkelijkheid is de deelnemer niet in de MUC — hij ontvangt geen presence, geen ops, geen chat, geen keyshares. De samenwerking is stil bevroren.

Trust boundary

Netwerk → Applicatie (reconnect-herstel). Geen externe aanvaller — een gewone netwerkdrop met een trage MUC-server volstaat.

Impact

De deelnemer valt onzichtbaar uit de samenwerking na een reconnect. Geen foutmelding, geen indicator — de UI toont nog steeds een "verbonden" status (de XMPP-sessie is hersteld), maar de MUC-kamer is weg. De deelnemer mist alle ops/chat/presence tot hij handmatig opnieuw verbindt.

Oplossingsrichting

Laat onRejoin een resultaat retourneren dat _reconnect kan controleren. Als de rejoin faalt (nick-conflict of een andere MucJoinFailure), moet de reconnect dat als een mislukking behandelen — continue naar de volgende backoff-poging, niet return met succes.
Nick-conflict-specifiek: bij een 409 conflict, wacht kort (de oude occupant-timeout zal vuren) en probeer opnieuw met een afgeleide nick (bijv. nick-2). Of stuur eerst een <presence type=unavailable> om de oude occupant expliciet uit te loggen vóór de herjoin.
Aanvullend: overweeg XEP-0045 §7.9 (Changing Nickname) of een MUC-destroy+re-create als de conflict aanhoudt.

Locatie

lib/xmpp/xmpp_session.dart regels 535–586 (_reconnect), specifiek regel 556 (onRejoin) en regel 557 (_reconnected.add)
lib/xmpp/xmpp_muc.dart regels 141–163 (join), 230–245 (_joinErrorOf — nickConflict)

Severity

HIGH — onzichtbaar verlies van samenwerking na een gewone netwerkdrop.

## Bevinding `lib/xmpp/xmpp_session.dart` — de supervised reconnect (`_reconnect`, regels 535–586) roept na een geslaagde re-authenticatie `onRejoin!(this)` aan (regel 556) om de MUC-kamer(s) opnieuw te betreden. De reconnect-logica controleert het resultaat van `onRejoin` niet — na `onRejoin` wordt `_reconnected.add(null)` gevuurd (regel 557) en `return`-t de functie met succes. ### Wat er gebeurt Na een netwerkdrop kan de MUC-server de oude occupant nog steeds als aanwezig beschouwen (de presence-timeout is nog niet gevuurd, typisch 60–300 seconden). Als `onRejoin` de kamer opnieuw probeert te betreden met dezelfde nick, stuurt de server een **409 conflict** error-presence. `XmppMuc.join` retourneert `MucJoinResult.failed(MucJoinFailure.nickConflict)`. Maar `_reconnect` negeert dit resultaat — het beschouwt de reconnect als geslaagd, vuurt `_reconnected`, en de transport-laag denkt dat alles weer synchroon is. In werkelijkheid is de deelnemer **niet in de MUC** — hij ontvangt geen presence, geen ops, geen chat, geen keyshares. De samenwerking is stil bevroren. ### Trust boundary Netwerk → Applicatie (reconnect-herstel). Geen externe aanvaller — een gewone netwerkdrop met een trage MUC-server volstaat. ### Impact De deelnemer valt onzichtbaar uit de samenwerking na een reconnect. Geen foutmelding, geen indicator — de UI toont nog steeds een "verbonden" status (de XMPP-sessie is hersteld), maar de MUC-kamer is weg. De deelnemer mist alle ops/chat/presence tot hij handmatig opnieuw verbindt. ### Oplossingsrichting 1. **Laat `onRejoin` een resultaat retourneren** dat `_reconnect` kan controleren. Als de rejoin faalt (nick-conflict of een andere `MucJoinFailure`), moet de reconnect dat als een mislukking behandelen — `continue` naar de volgende backoff-poging, niet `return` met succes. 2. **Nick-conflict-specifiek:** bij een 409 conflict, wacht kort (de oude occupant-timeout zal vuren) en probeer opnieuw met een afgeleide nick (bijv. `nick-2`). Of stuur eerst een `<presence type=unavailable>` om de oude occupant expliciet uit te loggen vóór de herjoin. 3. **Aanvullend:** overweeg XEP-0045 §7.9 (Changing Nickname) of een MUC-destroy+re-create als de conflict aanhoudt. ### Locatie - `lib/xmpp/xmpp_session.dart` regels 535–586 (`_reconnect`), specifiek regel 556 (`onRejoin`) en regel 557 (`_reconnected.add`) - `lib/xmpp/xmpp_muc.dart` regels 141–163 (`join`), 230–245 (`_joinErrorOf` — nickConflict) ### Severity HIGH — onzichtbaar verlies van samenwerking na een gewone netwerkdrop.

brenno added the

bug

label

2026-08-09 18:24:19 +00:00

brenno referenced this issue

2026-08-09 18:40:18 +00:00

XMPP: testgaten voor unhappy flows — bugs uit #1411-#1430 zijn niet gedekt door regressietests #1434

brenno added the

in-progress

label

2026-08-09 20:04:28 +00:00

brenno referenced this issue