XMPP: reconnect-machinery is niet aangesloten in productie + XmppMuc is niet herbruikbaar na reconnect #1421

New issue

Closed

opened 2026-08-09 18:28:37 +00:00 by brenno · 0 comments

brenno commented

2026-08-09 18:28:37 +00:00

Owner

Bevinding

Twee aanverwante stabiliteitsproblemen in de reconnect-keten.

1. Reconnect-machinery is nergens aangesloten in productie

lib/xmpp/xmpp_session.dart biedt supervised reconnect via reconnectTransportFactory en onRejoin (regels 137–138, 161–165). Maar in productiecode wordt XmppSession slechts één keer geconstrueerd — in lib/widgets/dialogs/xmpp_test_connection_dialog.dart regel 74 — zonder deze parameters. De collab-launch-functies hostXmppSession en joinXmppSession worden in lib/ nergens aangeroepen (alleen in test/).

Gevolg: zodra de XMPP-samenwerking in de app wordt geïntegreerd, zal een stream-drop de hele sessie killen (pre-reconnect gedrag) tenzij de integrator expliciet reconnectTransportFactory en onRejoin draad. Er is geen codepad dat dit doet, en er is geen documentatie die de integrator waarschuwt dat dit verplicht is.

2. XmppMuc.join() gooit StateError bij tweede aanroep

lib/xmpp/xmpp_muc.dart regel 142–144:

if (_joining != null || _joined) {
  throw StateError('XmppMuc.join() called more than once');
}

Na een geslaagde join is _joined = true. De onRejoin-callback die _reconnect aanroept (xmpp_session.dart regel 556) moet de MUC-kamer opnieuw betreden — maar kan niet dezelfde XmppMuc-instantie hergebruiken, want join() gooit. De integrator moet een nieuwe XmppMuc aanmaken, de oude teardown, en de demux-handlers opnieuw registreren. Maar de collab-launch houdt geen referentie naar de XmppMuc — de MUC wordt door de caller beheerd, en de launch gebruikt de demux direct op de stanza-channel.

Gevolg: zelfs als onRejoin wordt gedraad, is er geen schone manier om de kamer opnieuw te betreden zonder de hele collab-stack opnieuw op te bouwen. De reconnect is hiermee in de praktijk onbruikbaar.

Trust boundary

Interne architectuur — geen externe aanvaller. Een gewone netwerkdrop volstaat om het probleem zichtbaar te maken zodra de feature is geïntegreerd.

Impact

Zodra de XMPP-samenwerking in de app zit, killt elke netwerkdrop de hele sessie zonder herstel.
De reconnect-infrastructuur bestaat maar is onbruikbaar door het XmppMuc-hergebruiksprobleem.
De integrator die dit draad moet twee niet-obviate problemen oplossen (reconnect-factory + MUC-herjoin) zonder documentatie.

Oplossingsrichting

Voor probleem 1: bouw een integratielaag (provider/service) die XmppSession construeert met reconnectTransportFactory = () => openXmppFrameTransport(settings) en onRejoin die de MUC opnieuw betreedt. Documenteer dat dit verplicht is voor een productie-samenwerking.
Voor probleem 2: maak XmppMuc herbruikbaar na een join — voeg een rejoin()-methode toe die _joined en _joining reset en join() opnieuw kan aanroepen, of sta join() toe als de kamer is verlaten (_left = true). De demux-handlers hoeven dan niet opnieuw te worden geregistreerd.
Beter: laat de collab-launch zelf de XmppMuc beheren (in plaats van de caller), zodat onRejoin intern de kamer opnieuw kan betreden zonder dat de caller hiervan hoeft te weten.

Locatie

lib/xmpp/xmpp_session.dart regels 137–138, 161–165, 535–586 (reconnect-machinery)
lib/xmpp/xmpp_muc.dart regels 142–144 (join gooit StateError)
lib/xmpp/xmpp_collab_launch.dart regels 239–322 (hostXmppSession/joinXmppSession — geen MUC-beheer)
lib/widgets/dialogs/xmpp_test_connection_dialog.dart regel 74 (enige productie-XmppSession, zonder reconnect)

Severity

HIGH — de reconnect-keten is onbruikbaar zodra de feature wordt geïntegreerd.

## Bevinding Twee aanverwante stabiliteitsproblemen in de reconnect-keten. ### 1. Reconnect-machinery is nergens aangesloten in productie `lib/xmpp/xmpp_session.dart` biedt supervised reconnect via `reconnectTransportFactory` en `onRejoin` (regels 137–138, 161–165). Maar in productiecode wordt `XmppSession` slechts één keer geconstrueerd — in `lib/widgets/dialogs/xmpp_test_connection_dialog.dart` regel 74 — **zonder** deze parameters. De collab-launch-functies `hostXmppSession` en `joinXmppSession` worden in `lib/` nergens aangeroepen (alleen in `test/`). Gevolg: zodra de XMPP-samenwerking in de app wordt geïntegreerd, zal een stream-drop de hele sessie killen (pre-reconnect gedrag) tenzij de integrator expliciet `reconnectTransportFactory` en `onRejoin` draad. Er is geen codepad dat dit doet, en er is geen documentatie die de integrator waarschuwt dat dit verplicht is. ### 2. XmppMuc.join() gooit StateError bij tweede aanroep `lib/xmpp/xmpp_muc.dart` regel 142–144: ```dart if (_joining != null || _joined) { throw StateError('XmppMuc.join() called more than once'); } ``` Na een geslaagde join is `_joined = true`. De `onRejoin`-callback die `_reconnect` aanroept (xmpp_session.dart regel 556) moet de MUC-kamer opnieuw betreden — maar kan niet dezelfde `XmppMuc`-instantie hergebruiken, want `join()` gooit. De integrator moet een **nieuwe** `XmppMuc` aanmaken, de oude teardown, en de demux-handlers opnieuw registreren. Maar de collab-launch houdt geen referentie naar de `XmppMuc` — de MUC wordt door de caller beheerd, en de launch gebruikt de demux direct op de stanza-channel. Gevolg: zelfs als `onRejoin` wordt gedraad, is er geen schone manier om de kamer opnieuw te betreden zonder de hele collab-stack opnieuw op te bouwen. De reconnect is hiermee in de praktijk onbruikbaar. ### Trust boundary Interne architectuur — geen externe aanvaller. Een gewone netwerkdrop volstaat om het probleem zichtbaar te maken zodra de feature is geïntegreerd. ### Impact - Zodra de XMPP-samenwerking in de app zit, killt elke netwerkdrop de hele sessie zonder herstel. - De reconnect-infrastructuur bestaat maar is onbruikbaar door het `XmppMuc`-hergebruiksprobleem. - De integrator die dit draad moet twee niet-obviate problemen oplossen (reconnect-factory + MUC-herjoin) zonder documentatie. ### Oplossingsrichting 1. **Voor probleem 1:** bouw een integratielaag (provider/service) die `XmppSession` construeert met `reconnectTransportFactory = () => openXmppFrameTransport(settings)` en `onRejoin` die de MUC opnieuw betreedt. Documenteer dat dit verplicht is voor een productie-samenwerking. 2. **Voor probleem 2:** maak `XmppMuc` herbruikbaar na een join — voeg een `rejoin()`-methode toe die `_joined` en `_joining` reset en `join()` opnieuw kan aanroepen, of sta `join()` toe als de kamer is verlaten (`_left = true`). De demux-handlers hoeven dan niet opnieuw te worden geregistreerd. 3. **Beter:** laat de collab-launch zelf de `XmppMuc` beheren (in plaats van de caller), zodat `onRejoin` intern de kamer opnieuw kan betreden zonder dat de caller hiervan hoeft te weten. ### Locatie - `lib/xmpp/xmpp_session.dart` regels 137–138, 161–165, 535–586 (reconnect-machinery) - `lib/xmpp/xmpp_muc.dart` regels 142–144 (`join` gooit StateError) - `lib/xmpp/xmpp_collab_launch.dart` regels 239–322 (`hostXmppSession`/`joinXmppSession` — geen MUC-beheer) - `lib/widgets/dialogs/xmpp_test_connection_dialog.dart` regel 74 (enige productie-`XmppSession`, zonder reconnect) ### Severity HIGH — de reconnect-keten is onbruikbaar zodra de feature wordt geïntegreerd.

brenno added the

bug

label

2026-08-09 18:28:37 +00:00

brenno referenced this issue

2026-08-09 18:29:54 +00:00

XMPP: geen chat-geschiedenis (MAM) — late joiners en reconnecters verliezen het hele gesprek #1425

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