HarmenandClaude Opus 5
de955b607d
Het plan is gepromoveerd naar Actief/003-Testclient en tier A, en fase 1 is af. De uitkomst die het plan als eerste wilde weten: @evolu/nodejs 3.1.0 bevat geen client. Het pakket levert de relay plus losse bouwstenen, maar er is geen createEvoluDeps voor Node zoals @evolu/web die voor de browser heeft. De afhankelijkheden voor createEvolu worden nu samengesteld in tools/relay-client/src/evolu-node.js, uit de in-memory workers van @evolu/common; src/client.js is de publieke kant met eigenaars en blobs. Vier dingen zaten in de weg en alle vier faalden ze stil, met een instantie die het lijkt te doen tot de eerste schrijfactie: de ontbrekende installPolyfills (Node 24 mist Map.getOrInsertComputed), createEvoluDeps overslaan, de AsyncDisposableStack van initSharedWorker laten vallen, en workers zonder eigen reportDefect. Dat laatste is waarom de andere drie te vinden waren. Uitgeschreven in PLAN.md 4e. tests/test_client_lokaal.mjs schrijft daarom een blob weg en leest hem terug in plaats van alleen een instantie te maken, en heeft een wachthond: bij een defect in een worker blijft de suite anders hangen in plaats van rood te worden, en dat gebeurde bij de mutatietoets letterlijk. Beide mutaties lieten de juiste toets omvallen. Nog niet geprobeerd: praten met de relay. Daarvoor is het adres van de Umbrel nodig en dat komt van de gebruiker; het gaat niet in deze publieke repo. Suite: 405 goed, 0 fout over alle acht de toetsen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.7 KiB
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? Evolu probeert opnieuw en is ontworpen om een relay te overleven die er niet is. Als een weigering en een relay die plat ligt in de cliënt hetzelfde signaal geven, is de eerste proef uit
PLAN.md§4c niet af te lezen. De uitweg blijft binnen dit gereedschap: een eigen WebSocket-poging naast Evolu, met dezelfdeOwnerIdin de URL, die de statuscode wel te zien krijgt. Dat is een handeling van een paar regels, want deOwnerIdstaat in de URL van de verbinding (§10 van Upstream-evolu-relay.md). -
Wat is een zinnige blob om mee te experimenteren? Willekeurige bytes zijn genoeg voor de bytegrens, maar niet om te zien of gegevens werkelijk heen en weer gaan. Iets met leesbare inhoud en een teller is waarschijnlijk beter.
-
Wordt de gegevensmap van de proef opgeruimd? Twintig eigenaars die blijven staan is rommel, en het is sleutelmateriaal. Waarschijnlijk een opdracht die er één weggooit en één die alles weggooit.
-
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/entools/evolu-relay/hebben nu allebei@evolu/common8.7.0 en@evolu/nodejs3.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 uitPLAN.md§4e bij elke verhoging opnieuw langs moet. Beslissen bij de eerste verhoging, niet nu. -
Waar staat de relay voor deze cliënt? Het adres van de Umbrel staat nergens in deze repo en hoort daar ook niet in: dit is een publieke repo (zie
.gitignore, "Geheimen"). Dus een instelling die de gebruiker zelf zet, met een voorbeeldbestand ernaast. Voor de hand ligt.env.sample, want dat patroon staat al in de.gitignorevan de repo-root. -
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 eerstTask.jsin plaats van opnieuw te schuiven.