2026-09-09 12:59:55 +02:00
|
|
|
# Open punten - Testclient
|
|
|
|
|
|
|
|
|
|
> Vragen die het plan niet beantwoordt en die tijdens het werk beslist moeten worden. Wat af is, verhuist
|
|
|
|
|
> naar [PROGRESS.md](PROGRESS.md); wat een taak wordt, naar [TAKEN.md](TAKEN.md).
|
|
|
|
|
|
2026-09-09 13:39:47 +02:00
|
|
|
1. ~~**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.
|
2026-09-09 12:59:55 +02:00
|
|
|
|
2026-09-09 13:39:47 +02:00
|
|
|
2. **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.
|
2026-09-09 12:59:55 +02:00
|
|
|
|
2026-09-09 13:39:47 +02:00
|
|
|
3. **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.
|
2026-09-09 12:59:55 +02:00
|
|
|
|
|
|
|
|
4. **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).
|
|
|
|
|
|
|
|
|
|
5. **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.
|
|
|
|
|
|
2026-09-09 13:39:47 +02:00
|
|
|
6. ~~**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](TAKEN.md).
|
2026-09-09 12:59:55 +02:00
|
|
|
|
2026-09-09 13:39:47 +02:00
|
|
|
7. **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.
|
|
|
|
|
|
|
|
|
|
8. **`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.
|
|
|
|
|
|
|
|
|
|
9. **Het afsluiten is opgelost maar niet doorgrond.** De volgorde in `dispose` (afhankelijkheden, dan een
|
2026-09-09 12:59:55 +02:00
|
|
|
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.
|