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>
6.4 KiB
6.4 KiB
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
- 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/common8.7.0 en@evolu/nodejs3.1.0 geïnstalleerd intools/relay-client/(09-09-2026)- Vastgesteld dat
@evolu/nodejsgéén cliënt bevat, alleen de relay plus losse bouwstenen. De afhankelijkheden voorcreateEvoluworden daarom zelf samengesteld insrc/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 eenUint8Array-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: éénowners.jsonmet naam, mnemonic enOwnerId, geschreven via een tijdelijk bestand en een hernoeming. HetOwnerIdwordt 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.sampleernaast). Gebouwd maar niet beproefd, want er is nog geen adres; dat is de volgende stap - Een blob schrijven met een instelbare omvang, en teruglezen.
schrijfenlees, met--bytesen--lokaal - De losse WebSocket-poging die de HTTP-statuscode wél te zien krijgt:
src/probe.jsen de opdrachtklop. Metnode:httpen niet met de WebSocket van Node, want die geeft je bij een weigering eenerroren geen 401. Daarmee is OPEN.md punt 1 opgelost vóórdat het een probleem werd
Fase 3 - het bedieningsvlak (af, 09-09-2026)
- De HTTP-server met de pagina, op localhost.
src/ui.jsensrc/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.batenStart.command, op verzoek van de gebruiker. Ze draaiennpm installals het nodig is, waarschuwen als.envontbreekt, 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
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, wantregister.js,argumenten.jsenconfig.jsraken Evolu niet aan - Een vaste mnemonic met een vast verwacht
OwnerId, intests/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 vanhttp://naarws:// - Afsluiten en heropenen, en dat is er een die een echte fout vasthoudt:
evolu.insertzet de schrijfactie in de wachtrij en geeft meteen een id terug, dus wie vlak daarna afsluit is de rij kwijt.schrijfwacht 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 heefttest_client_lokaal.mjsnu een wachthond van dertig seconden