Files
HarmenandClaude Opus 5 090843a523 Testclient: losmaken maakt nu werkelijk los
Gemeld door de gebruiker: een eigenaar uit het register halen liet de relay hem
zien tot het proces stopte. `vergeet` koppelt netjes af, maar de socket zit niet
in de Evolu-instantie: hij zit in de gedeelde worker, en die blijft staan zolang
er nog een eigenaar open is. Een transport dat je in de config van `createEvolu`
meegeeft, kun je daarna nergens opzeggen.

Nu start de instantie met `transports: []` en gaat de transport erin met
`evolu.useOwner`, ook al is het de eigen appOwner. Die geeft een opzegging terug
en Evolu telt de verwijzingen, dus de laatste opzegging sluit de socket.

Bewezen met een wegwerpproef tegen een relay op localhost die iedereen toelaat:
twee eigenaars open, dan de ene sluiten. Gemeten in de verbindingstabel van het
besturingssysteem en niet met de `dicht`-melding van de cliënt, want
`closeSocket` in @evolu/common zet `socket.onclose` op null voordat het sluit.
Oude vorm: 2 verbindingen na het sluiten. Nieuwe vorm: 1, en de andere eigenaar
kon daarna nog schrijven.

Suite groen: 42, 90, 36, 22, 54 en 68 goed, 0 fout.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-10 09:55:05 +02:00

7.9 KiB
Raw Permalink Blame History

Taken - Testclient

Prioriteit: A | Afhankelijk van:

Nieuw en meteen actief op 09-09-2026. Het masterplan werd dezelfde dag geschreven en op verzoek van de gebruiker direct gepromoveerd. Nummer 003, onder de bestaande 005: tier A was leeg en dit is nu de lopende focus, dus de bovenkant van de reeks klopt weer.

Waarom dit plan er is: vier beweringen over Evolu Relay rusten op redenering uit de broncode in plaats van op een proef, waaronder dat blokkeren pas bij de volgende verbinding werkt. Zonder een cliënt die geen hardware nodig heeft, blijft dat zo.

Volgende stap

  • Fase 4 afmaken, nu 0.7.0 op het apparaat draait. De wachtlijst is daar de enige weg naar binnen, dus de drie proeven die een toegelaten eigenaar nodig hebben kunnen. Ze vragen om en om een handeling van de gebruiker op de statuspagina en een ronde met de cliënt
  • Losmaken maakte niets los (10-09-2026). Gemeld door de gebruiker: een eigenaar uit het register halen liet de relay hem zien tot het proces stopte. De socket zit in de gedeelde worker, niet in de instantie, en een transport uit de config van createEvolu is nergens meer op te zeggen. Nu start de instantie met transports: [] en gaat de transport erin met evolu.useOwner, die een opzegging teruggeeft. Bewezen tegen een relay op localhost: met de oude vorm bleven het 2 verbindingen na het sluiten van de ene eigenaar, met de nieuwe 1
  • De logregels van de relay-container lezen, want daar zit het antwoord op OPEN.md punt 9. Twee eigenaars die toegelaten waren zijn uit de allowlist verdwenen, en de cliënt kan niet zien waarom. Gezocht wordt naar learned a new owner, owners.json was unreadable, refused a write of N bytes, en of de container herstart is. Eigenaar: gebruiker, want alleen die komt bij het apparaat. Die laatste regel is meteen de proef over de bytegrens, die van de cliëntkant onzichtbaar is

Fase 1 - de samenstelling (af)

  • @evolu/common 8.7.0 en @evolu/nodejs 3.1.0 geïnstalleerd in tools/relay-client/ (09-09-2026)
  • Vastgesteld dat @evolu/nodejs géén cliënt bevat, alleen de relay plus losse bouwstenen. De afhankelijkheden voor createEvolu worden daarom zelf samengesteld in src/evolu-node.js; zie PLAN.md §4e voor de vier valstrikken die dat kostte
  • Bewezen dat het werkt zonder relay (09-09-2026): een eigenaar aanmaken, een Evolu-instantie met transports: [], een rij met een Uint8Array-kolom wegschrijven en teruglezen. De bytes komen er ongeschonden uit en het proces sluit schoon af, zonder defect en zonder te blijven hangen

Fase 2 - de opdrachtregel (af, 09-09-2026)

  • Een eigenaar aanmaken en bewaren. src/register.js: één owners.json met naam, mnemonic en OwnerId, geschreven via een tijdelijk bestand en een hernoeming. Het OwnerId wordt afgedrukt, de mnemonic nooit
  • Aanmaken, opsommen, teruglezen, weggooien. nieuw, lijst, vergeet. Vergeten is vergeten: de lokale database blijft staan en op de relay verandert er niets, en dat zegt de uitdraai er ook bij
  • Verbinden met de relay via createOwnerWebSocketTransport, met het adres uit .env (src/config.js, met .env.sample ernaast). Gebouwd maar niet beproefd, want er is nog geen adres; dat is de volgende stap
  • Een blob schrijven met een instelbare omvang, en teruglezen. schrijf en lees, met --bytes en --lokaal
  • De losse WebSocket-poging die de HTTP-statuscode wél te zien krijgt: src/probe.js en de opdracht test (tot 09-09-2026 klop geheten, hernoemd op voorstel van de gebruiker). Met node:http en niet met de WebSocket van Node, want die geeft je bij een weigering een error en geen 401. Daarmee is OPEN.md punt 1 opgelost vóórdat het een probleem werd
  • spiegel <naam>, de enige proef die van de cliëntkant kan bewijzen dat er werkelijk iets op de relay staat: dezelfde eigenaar in een lege database ernaast

Fase 3 - het bedieningsvlak (af, 09-09-2026)

  • De HTTP-server met de pagina, op localhost. src/ui.js en src/index.html, geen framework en geen bouwstap, net als de twee statuspagina's
  • De lijst met eigenaars, met per eigenaar de toestand, het aantal blobs en de knoppen uit PLAN.md §4b: aankloppen, verbinden, verbreken, blob schrijven met omvang, lezen, vergeten
  • Het log, met tijdstip per gebeurtenis
  • Start.bat en Start.command, op verzoek van de gebruiker. Ze draaien npm install als het nodig is, waarschuwen als .env ontbreekt, openen de browser en houden het venster open bij een fout
  • In de browser nagekeken (09-09-2026): een blob schrijven en teruglezen werkt vanuit de pagina, de gegevens zijn dezelfde als die van de opdrachtregel, en licht en donker kloppen allebei
  • "Verbinden" gaat uit na een weigering (09-09-2026, voorstel van de gebruiker), en een lopende verbinding die blijft falen test zichzelf één keer en stopt bij een weigering. Dat laatste is de eigenlijke opbrengst: zonder die rem vult één geweigerde verbinding de weigerlijst van de relay met pogingen, en dat is tijdens deze sessie ook gebeurd

Fase 4 - de proeven

De zes proeven staan in PLAN.md §4c. Ze zijn handwerk en hebben een draaiende relay nodig, dus ze komen na fase 2 en kunnen deels vóór fase 3.

  • Onbekende eigenaar met het venster dicht: 401 (09-09-2026). Twee eigenaars, allebei geweigerd op wss:// via de reverse proxy. Daarmee is de bewering uit §10 van het naslagdocument geen redenering uit de broncode meer maar gezien gedrag, en er is gratis bij bewezen dat de proxy de WebSocket-upgrade doorlaat. Wat de gebruiker nog moet nakijken: staan die twee in de weigerlijst op de statuspagina? Dat deel kan deze cliënt niet zien
  • Toelaten en opnieuw verbinden: komt de hele geschiedenis alsnog binnen
  • Blokkeren tijdens een lopende verbinding: blijft hij schrijven tot de volgende verbinding
  • Het venster van twee minuten met de pagina dicht
  • Eén blob boven RELAY_MAX_WRITE_BYTES, en meerdere kleinere die samen groter zijn
  • Twee eigenaars tegelijk verbonden
  • De uitkomsten terugschrijven naar §10 van Upstream-evolu-relay.md en naar open punt 10 van het plan Umbrelapp. Dit is de opbrengst van het hele plan; zonder deze stap blijft het gereedschap zonder resultaat

Fase 5 - de toetsen (af, 09-09-2026)

Wat automatisch kan is klein, en PLAN.md §7 zegt waarom.

  • Het register, in tests/test_client_register.mjs: aanmaken, teruglezen, een naam die al bestaat, een onleesbaar bestand, een onbekende versie. Deze toets heeft géén pakketten nodig, want register.js, argumenten.js en config.js raken Evolu niet aan
  • Een vaste mnemonic met een vast verwacht OwnerId, in tests/test_client_lokaal.mjs. Dit is de toets die omvalt als Evolu onder ons iets anders gaat doen met de afleiding
  • Het lezen van de opdrachtregel en van .env, met de omzetting van http:// naar ws://
  • Afsluiten en heropenen, en dat is er een die een echte fout vasthoudt: evolu.insert zet de schrijfactie in de wachtrij en geeft meteen een id terug, dus wie vlak daarna afsluit is de rij kwijt. schrijf wacht daarom op een query erachter
  • Mutatie-getest, drie keer: de polyfill uitzetten, de dubbele-naam-controle uitzetten, en de omzetting van http:// slopen. Alle drie lieten de júiste toets omvallen. De eerste liet zien dat de suite bij een defect in een worker blíjft hangen in plaats van rood te worden, en daarom heeft test_client_lokaal.mjs nu een wachthond van dertig seconden