connectModule: refcounted Shared-Provider-Pool (WS/Doc-Sharing bei Cross-Module-Reads)

[gergernaut]

Kontext (aus dem Review zu #145): Cross-Module-Reads öffnen aktuell je eine eigene WebSocket + ein eigenes Y.Doc, ohne Sharing. Ein Modul, das ein fremdes Doc read-only mitliest, bündelt sich nicht mit anderen Konsumenten desselben Docs.

Ist-Zustand (unkritisch beim Zielmaßstab ~10–20 Nutzer):

• Views werden conditional gerendert → nur ein Modul-View gleichzeitig gemountet; beim Wechsel conn.destroy() (WS zu). Taktische Übersicht und Einsatzabschnitte sind nie gleichzeitig offen.
• Dauerhaft offen: chat + activity. Pro Moment also ~5 WS (aktiver View + 2), nicht 6.
• Trend: je mehr Module sich gegenseitig lesen, desto mehr parallele WS/Docs pro Client.

Vorschlag (Hardening, Prio niedrig): refcounted Shared-Provider-Pool in packages/web/src/sync/provider.ts, keyed nach room×module:

• N Komponenten, die dasselbe (room, module) verbinden, teilen sich eine WS + ein Y.Doc.
• Refcount hoch beim connectModule, runter beim destroy; realer provider.destroy()/doc.destroy() erst beim letzten Release.
• Aufrufer-API bleibt unverändert (connectModule(...) gibt weiter { doc, provider, destroy } zurück).

Nicht Teil von Milestone #3 — künftiger Härtungs-/Ausbau-Milestone. Kein akuter Handlungsbedarf; hier festgehalten, damit es nicht verloren geht.

[SuperSummiBot]

Einschätzung

Der Vorschlag ist architektonisch richtig und elegant — genau die Lösung für das Thema, das ich in den Reviews zu #144 und #145 als „worth noting" markiert hatte (zunehmende cross-module WS-Verbindungen).

Was ich am Vorschlag besonders schätze:

1. API bleibt unverändert: connectModule(...) gibt weiter { doc, provider, destroy } zurück. Keine Änderung an den Komponenten (Einsatzabschnitte, Taktische Übersicht, Kräfteübersicht) — reine Infrastruktur-Änderung in provider.ts.

2. Refcounting ist korrekt: Mehrere Komponenten, die dasselbe (room, module) verbinden, teilen sich eine WS + ein Y.Doc. Der letzte destroy() schließt wirklich. Reduziert die WS-Anzahl drastisch — z. B. wenn EA-Modul und Taktische Übersicht beide kraefteubersicht read-only mitlesen, teilen sie sich eine Verbindung statt zwei.

3. Prio niedrig ist richtig: Wie im Issue-Body richtig steht: Views werden conditional gerendert, nur ein Modul-View ist gleichzeitig gemountet. Die aktuellen ~5 WS pro Client sind für den Zielmaßstab (~10–20 Nutzer) unproblematisch. Das ist Hardening, kein Bug.

Ein technischer Punkt für die Umsetzung (wenn's irgendwann gemacht wird):

Der cache-Parameter in connectModule (für y-indexeddb, #70) muss sauber mit dem Pool interagieren. Wenn eine Verbindung mit cache: false (z. B. Export/Import) und eine mit cache: true (langlebige Modul-View) denselben (room, module) teilen würden, müsste der Pool entscheiden, ob die IndexedDB-Persistenz aktiv ist. Vermutlich OR-Verknüpfung: wenn einer der Aufrufer cache will, dann cache. Nicht trivial, aber machbar.

Fazit: Sehr guter Vorschlag, richtig priorisiert (niedrig, nicht akut), architektonisch sauber. Sollte als künftiger Härtungs-Milestone festgehalten werden — genau wie vorgeschlagen.

[gergernaut]

Verifikation Ist-Zustand (Stand 2026-08-29): Mount-Struktur und alle connectModule-Aufrufer geprüft — heute entsteht keine gleichzeitige Doppelverbindung auf dasselbe (room, module):

• AppShell mountet immer genau einen Feature-View (activeView === …, lazy). Dauerhaft offen sind nur chat (+ Awareness/Präsenz) und activity.
• Cross-Module-Reads sind pro View durchweg verschiedene Module (z. B. Arbeitsblatt liest arbeitsblatt + kraefteubersicht + einsatzabschnitte) — keine Dopplung innerhalb eines Views, und da nie zwei Feature-Views gleichzeitig gemountet sind, auch keine viewübergreifende.
• Übersicht verbindet kein Modul (Daten via Props/useRoomActivity); Bundle-Export/Import läuft von dort mit cache: false, ohne gleichzeitig gemounteten Feature-View.
• Awareness/Präsenz wird ausschließlich im chat genutzt (einmalig) → für die Read-only-Konsumenten wäre ein geteiltes Doc unkritisch.

Fazit: Der refcounted Pool würde aktuell null Verbindungen bündeln — reines Future-Proofing, wie im Issue vermerkt. Ein Eingriff in den invariantenkritischen Sync-Kern (provider.ts, Invariante #2/disableBc) ohne aktuellen Nutzen wäre das Risiko nicht wert (Refcount-Bug ⇒ geleaktes WS oder verfrühtes doc.destroy() quer über alle Module; zusätzlich cache:true/cache:false-Divergenz zwischen View- und Export-Konsumenten).

Trigger für die Umsetzung (dann lohnt es sich): sobald ein View mehrere Modul-Reader gleichzeitig mountet (z. B. ein Dashboard/kombinierter View) oder dauerhaft laufende Hintergrund-Reader hinzukommen, sodass dasselbe (room, module) real von mehreren Konsumenten gleichzeitig gehalten wird.

Entscheidung: vorerst deferren (offen lassen), nicht auf Vorrat bauen. Umsetzungsskizze bleibt gültig: reiner, unit-getesteter createRefcountedPool-Helfer + Key inkl. cache-Flag, Aufrufer-API unverändert.