Testclient: gedeelde afhankelijkheden, en zicht op de WebSocket

Een fout van ons, gevonden door de gebruiker bij de tweede eigenaar: "Expected
tab leader port.". createEvoluDeps vraagt via navigator.locks het slot "tab" aan
en kondigt de houder aan als tab leader, en dat slot kan er maar een hebben.
openStore maakte per eigenaar een eigen stel afhankelijkheden, dus de tweede
werd nooit leider. Nu een stel per proces met een teller, zodat het pas
opgeruimd wordt als de laatste store sluit. Dit stond al als valstrik 2 in
PLAN.md 4e en was er alsnog in geslopen; de toets met twee eigenaars tegelijk
brengt hem terug zodra iemand dit ongedaan maakt.

Twee dingen erbij om te kunnen zien wat er met de relay gebeurt:

- spiegel <naam> opent dezelfde eigenaar in een lege database naast de
  bestaande. Alles wat daar binnenkomt heeft de heen- en terugreis over de relay
  gemaakt, en dat is de enige manier waarop de clientkant kan bewijzen dat er
  werkelijk iets op de relay staat; lees toont je altijd je eigen rijen.
- onWebSocket meldt welke URL geopend wordt en wat ermee gebeurt. Zonder dat
  ziet een relay die de socket dichtgooit er hetzelfde uit als een trage relay.

Dat luikje gaf meteen het antwoord: de socket komt nooit open, 1006, in een
herhaallus, en met het ws-pakket ernaast staat er wat de globale WebSocket
verzwijgt: 401. Twee eigenaars die eerder allebei 101 gaven zijn dus uit de
allowlist van de relay verdwenen. Dat is een vraag over de server-app en staat
als open punt 9, met vier verklaringen en wat ze uit elkaar houdt.

Suite: 478 goed, 0 fout.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Harmen
2026-09-09 14:15:09 +02:00
co-authored by Claude Opus 5
parent 64ba74e053
commit 3f7da42388
8 changed files with 306 additions and 11 deletions
@@ -60,3 +60,33 @@ dus de relay is over `wss://` bruikbaar. Dat raakt het masterplan **Bereikbaarhe
Wat deze cliënt niet kan zien, en dus bij de gebruiker ligt: staan die twee eigenaars in de weigerlijst op
de statuspagina van de app?
## 09-09-2026 - een eigen fout, en daarna een vraag aan de relay
De gebruiker liet beide eigenaars toe en kreeg meteen een defect op de tweede: "Expected tab leader port.".
**Een fout van ons, en precies de valstrik die in `PLAN.md` §4e als nummer 2 staat opgeschreven.**
`createEvoluDeps` vraagt via `navigator.locks` het slot "tab" aan en kondigt de houder aan als tab leader;
dat slot kan er maar één hebben. `openStore` maakte per eigenaar een eigen stel afhankelijkheden, dus de
tweede werd nooit leider. In een browser is dit vanzelf goed: daar is er één tabblad met één gedeelde
worker. Nu één stel per proces, met een teller zodat het pas opgeruimd wordt als de laatste store sluit,
en een toets met twee eigenaars tegelijk die de fout terugbrengt zodra iemand dat ongedaan maakt.
Daarna bleek er niets te synchroniseren. Twee dingen erbij gebouwd om dat überhaupt te kúnnen zien:
- **`spiegel <naam>`** opent dezelfde eigenaar in een lege database naast de bestaande. Alles wat daar
binnenkomt heeft de heenreis en de terugreis over de relay gemaakt, en dat is de enige manier waarop de
cliëntkant kan bewijzen dat er werkelijk iets op de relay staat. `lees` toont je namelijk altijd je eigen
rijen, ook als de relay ze nooit gezien heeft;
- **een luikje op de WebSocket** (`onWebSocket`), dat meldt welke URL er geopend wordt en wat ermee
gebeurt. Zonder dat ziet een relay die de socket dichtgooit er hetzelfde uit als een relay die traag is:
Evolu probeert het gewoon opnieuw.
Dat luikje gaf het antwoord in één keer: de socket komt nooit open, `WebSocketConnectError` en sluitcode
1006, in een herhaallus. Met het `ws`-pakket ernaast gelegd staat er wat de globale WebSocket verzwijgt:
**HTTP 401.** En `klop` zegt dat inmiddels ook, voor allebei de eigenaars, terwijl diezelfde opdracht
kort daarvoor nog twee keer 101 gaf.
**Daarmee ligt de vraag bij de relay en niet meer bij de cliënt: twee eigenaars die toegelaten waren zijn
uit de allowlist verdwenen.** Wat er op de statuspagina van staat is "turned away". Wat dit kan zijn staat
in [OPEN.md](OPEN.md) punt 10; het antwoord zit in de logregels van de relay-container en die kan alleen de
gebruiker lezen.