De testkudde mag zelf geen bron van twijfel zijn (shaer-6wt)
Barts opdracht: zoeken aan de kant van de daemon. Dat leverde geen fout in de
handshake op, maar wel twee dingen die het ONDERZOEK onbetrouwbaar maakten.
HET BEWIJS KLOPTE ZELF NIET. /log toonde een Follow die state.json niet kende: er
werd alleen weggeschreven in takken die toch al iets bewaarden. Bij een kudde die
je gebruikt om een fout te vinden is dat het ergste wat er is -- dan zoek je in
bewijs dat zelf niet deugt. Elke regel gaat nu meteen naar schijf.
En UITGAAND wordt nu ook genoteerd, met de statuscode erbij. "Hij stuurde een
Accept" was tot dat moment een aanname; nu staat er dat dev er 202 op gaf, en pas
daarmee is de daemon-kant echt uitgesloten.
MIJN ACCEPT WEEK AF VAN KLONKT: ik stuurde het hele Offer als object, Klonkt
stuurt daar een id-string. Het gedrag verandert er niet van, maar een testkudde
die er anders uitziet dan een echte implementatie laat je een verschil
onderzoeken dat je zelf hebt gemaakt.
Wat het spoor nu zegt, en dat is nog een LEAD en geen conclusie: dev commit wel
(het volgt de ward) maar stuurt zijn afsluitende Accept niet, dus de ward houdt
een lege shaer:guardians. In handshake.js doet de uitgaande accept-tak een
recordAccept EN een fanout; de inkomende tak op regel 600 alleen recordAccept en
maybeCommit. Waarom het bij @mee wel lukte is nog onverklaard, en zonder die
verklaring is een fix een gok.
Los daarvan: er staat nu een start.sh. De farm stierf drie keer mee met mijn
ssh-sessie, en twee van die keren zocht ik naar een fout terwijl er domweg niets
draaide.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
