Files

T

HarmenandClaude Opus 5 f0809a80c2 Testclient fase 2, 3 en 5: opdrachtregel, bedieningsvlak en toetsen

De client staat. Een register (owners.json met naam, mnemonic en OwnerId), acht
opdrachten op de opdrachtregel, en een bedieningsvlak op 127.0.0.1:4380 met per
eigenaar de knoppen uit PLAN.md 4b. Start.bat en Start.command erbij op verzoek
van de gebruiker: die draaien npm install als het nodig is, waarschuwen als .env
ontbreekt, openen de browser en houden het venster open bij een fout.

OPEN.md punt 1 is opgelost voordat het een probleem werd. src/probe.js doet de
WebSocket-upgrade met node:http in plaats van met de WebSocket van Node, want
die geeft je bij een weigering een error en geen statuscode. De opdracht klop en
de knop Aankloppen tonen dus 101 of 401, en dat is precies wat de proeven uit
4c moeten kunnen aflezen.

Twee echte fouten gevonden en vastgezet in een toets. De databasemap werd niet
aangemaakt, en omdat better-sqlite3 dat in een worker meldt was het symptoom een
lees die nooit antwoordde. En evolu.insert geeft meteen een id terug maar zet de
schrijfactie in de wachtrij van de worker, dus wie vlak daarna afsluit is de rij
kwijt; schrijf wacht nu op een query erachter en de toets sluit af en heropent.

tests/test_client_register.mjs heeft geen pakketten nodig, want register.js,
argumenten.js en config.js raken Evolu niet aan. Drie mutaties geprobeerd en
alle drie lieten de juiste toets omvallen.

In de browser nagekeken: schrijven en teruglezen werkt vanuit de pagina, de
gegevens zijn dezelfde als die van de opdrachtregel, en licht en donker kloppen.

Alles wat de relay raakt is gebouwd en niets ervan is beproefd; daarvoor wacht
er een RELAY_URL in .env, en die komt van de gebruiker.

Suite: 475 goed, 0 fout over alle negen de toetsen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-09-09 13:39:47 +02:00

3.8 KiB

Raw Blame History

Open punten - Testclient

Vragen die het plan niet beantwoordt en die tijdens het werk beslist moeten worden. Wat af is, verhuist naar PROGRESS.md; wat een taak wordt, naar TAKEN.md.

~~Hoe zichtbaar is een 401 in de cliënt?~~ Opgelost op 09-09-2026, vóórdat het een probleem werd. src/probe.js doet de WebSocket-upgrade zelf met node:http en leest de statuscode af; de opdracht klop en de knop "Aankloppen" tonen 101 of 401. Met node:http en niet met de WebSocket van Node, en dat is de hele reden dat dat bestand bestaat: die laatste geeft je bij een weigering een error en geen status, en 401 tegenover 404 tegenover "niets luistert" is precies wat je wilt weten. Wat er nog niet is, is een keer zien dat het klopt tegen een echte relay.
Wat is een zinnige blob om mee te experimenteren? Voorlopig een oplopend bytepatroon (i % 256) met een label erbij: genoeg om de bytegrens te raken en om bij het teruglezen te zien dát het jouw bytes zijn. Wat er nog niet is, is inhoud die iets betekent, en dat gaat pas meespelen zodra twee eigenaars werkelijk iets over de relay uitwisselen.
De gegevensmap wordt niet opgeruimd. vergeet haalt een eigenaar uit het register en laat zijn database staan; dat staat er ook bij in de uitdraai. Zolang het er een handvol zijn is dat prima, maar het is wél sleutelmateriaal dat je dan kwijt bent zonder het weg te gooien. Een opdracht die de database meeneemt hoort erbij, en misschien een die alles opruimt.
Data per eigenaar wissen op de relay staat al open bij Umbrelapp. Dit gereedschap maakt dat makkelijk te beproeven maar lost het niet op; het blijft schrijven in andermans schema (§8 van hetzelfde naslagdocument).
Bevriest deze cliënt de versie van Evolu, of loopt hij mee? tools/relay-client/ en tools/evolu-relay/ hebben nu allebei @evolu/common 8.7.0 en @evolu/nodejs 3.1.0, en dat is geen toeval maar ook geen afspraak. Meelopen is het eerlijkst, want dan beproef je wat er draait; het kost wel dat de samenstelling uit PLAN.md §4e bij elke verhoging opnieuw langs moet. Beslissen bij de eerste verhoging, niet nu.
~~Waar staat de relay voor deze cliënt?~~ Beslist op 09-09-2026: RELAY_URL in .env, met .env.sample als voorbeeld in de repo. Het adres van de Umbrel staat nergens in deze repo en hoort daar ook niet in; dit is een publieke repo (zie .gitignore, "Geheimen"). Wat er nog niet is, is de waarde, en dat is de volgende stap in TAKEN.md.
Het bedieningsvlak tekent de hele lijst opnieuw. Er zit nu een vergelijking voor: verandert de status niet, dan gebeurt er niets. Dat was nodig omdat het veld met de omvang anders elke drie seconden leegging terwijl je erin typt. Wordt de lijst langer of komt er meer per eigenaar bij, dan is dit het punt waarop het opnieuw gaat schuren, en dan is per eigenaar bijwerken de juiste stap. Nu niet: dat is machinerie voor een probleem dat er nog niet is.
sync en het bedieningsvlak weten niet of een verbinding er nog is. Er staat "verbonden" zodra de instantie gemaakt is, en Evolu meldt niet dat de relay weggevallen is (hij probeert het gewoon opnieuw). Voor de proeven is klop het antwoord, maar op de pagina staat een groen bolletje dat meer belooft dan het weet. Evolu heeft een SyncState; uitzoeken of daar iets bruikbaars in zit.
Het afsluiten is opgelost maar niet doorgrond. De volgorde in dispose (afhankelijkheden, dan een tik doorlaten, dan de resources van de gedeelde worker, dan de runs) is gevonden door te proberen, niet door de bron van Evolu te lezen. Hij werkt en er is een reden bij opgeschreven, maar het is geen bewijs. Valt het bij een volgende versie opnieuw om, lees dan eerst Task.js in plaats van opnieuw te schuiven.

3.8 KiB Raw Blame History

Open punten - Testclient

3.8 KiB

Raw Blame History