HarmenandClaude Opus 5
04c20a37f0
Voorstel van de gebruiker, en het tweede deel loste meer op dan een knop. Een verbinding die geweigerd wordt bleef eindeloos opnieuw proberen, en elke poging is een regel in de weigerlijst van de relay; zo liep die lijst tijdens deze sessie ook vol. - klop heet test op de opdrachtregel en Testen op de pagina. - Verbinden gaat uit zodra een test zegt dat de eigenaar geweigerd wordt, met de uitkomst in het rood naast de naam. Onbekend telt als toegestaan, want anders moet je eerst testen om iets te mogen en is dat zelf ook een poging. Blob schrijven gaat door dezelfde poort en schrijft dan lokaal verder. - Een lopende verbinding stopt zichzelf: na drie mislukte sockets wordt er precies een keer getest, en bij een weigering gaat de verbinding eruit. Is het geen weigering, dan blijft hij staan, want dan is opnieuw proberen juist goed. De melding in een dialoogvenster is eruit; de uitkomst staat naast de naam en in het log en die blijven staan. In de browser nagekeken: testen geeft 401, de regel verschijnt rood, en Verbinden is uitgegrijsd voor de geteste eigenaar terwijl de ongeteste hem houdt. Suite: 478 goed, 0 fout. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
82 lines
6.1 KiB
Markdown
82 lines
6.1 KiB
Markdown
# 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).
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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).
|
|
|
|
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).
|
|
**Deels opgelost op 09-09-2026:** het bedieningsvlak telt mislukte sockets en test na drie mislukkingen
|
|
één keer, zodat een geweigerde eigenaar niet eindeloos blijft kloppen. Wat er nog niet is, is een groen
|
|
bolletje dat werkelijk "er staat nu een verbinding" betekent in plaats van "we hebben er een geopend".
|
|
Evolu heeft een `SyncState`; uitzoeken of daar iets bruikbaars in zit.
|
|
|
|
9. **Twee toegelaten eigenaars zijn uit de allowlist van de relay verdwenen (09-09-2026), en we weten
|
|
niet waarom.** Ze gaven allebei 101 en even later allebei 401, met "turned away" op de statuspagina.
|
|
Dit is een vraag over de **server-app**, niet over de cliënt, en het is de eerste keer dat dit
|
|
gereedschap iets over de relay aan het licht brengt. Vier verklaringen, in volgorde van
|
|
waarschijnlijkheid:
|
|
|
|
1. **de relay is herstart voordat de allowlist weggeschreven was.** `isOwnerAllowed` zet alleen
|
|
`dirty`; het wegschrijven gebeurt in de lus. Een herstart in dat gat kost de net geleerde eigenaars.
|
|
`restart: on-failure` staat in de compose, dus een herstart hoeft niet opgemerkt te zijn;
|
|
2. **`owners.json` is als onleesbaar terzijde geschoven.** Daar heeft de relay een eigen logregel voor
|
|
("owners.json was unreadable and has been moved aside"). Minder waarschijnlijk, want `writeState`
|
|
schrijft via een tijdelijk bestand en een hernoeming, dus een halve schrijfactie hoort niet te
|
|
kunnen;
|
|
3. **de blob van 2 MB heeft de relay laten struikelen.** Die zat boven `RELAY_MAX_WRITE_BYTES` en werd
|
|
vlak voor het verdwijnen geschreven. Als dat een herstart gaf, is dit verklaring 1 met een oorzaak;
|
|
4. de leerstand liet ze toe zonder ze te bewaren, en dan is er iets mis in `store.js`.
|
|
|
|
**Wat het uit elkaar houdt zijn de logregels van de relay-container**, en die kan alleen de gebruiker
|
|
lezen: `learned a new owner`, `owners.json was unreadable`, `refused a write of N bytes`, plus of de
|
|
container herstart is. Die laatste regel is bovendien de proef over de bytegrens, die van de
|
|
cliëntkant onzichtbaar is.
|
|
|
|
10. **De bytegrens is van de cliëntkant niet te zien.** Een blob van 2 MB schrijven levert geen enkele
|
|
melding op: de cliënt is local-first, dus de rij staat er lokaal hoe dan ook, en de relay meldt een
|
|
geweigerde schrijfactie alleen in zijn eigen log. `spiegel` kan het indirect aantonen (de blob komt
|
|
dan niet terug), maar alleen als de synchronisatie verder werkt.
|
|
|
|
11. **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.
|