Changeset 44dfbd2 in Klonkt for test/move-guardianship.test.js

Timestamp:

08/13/2026 08:32:21 PM (4 weeks ago)

Author:

Robin <roboburr@…>

Branches:

main

Children:

4766720

Parents:

54b027a

Message:

Eerst de guardianship verhuizen, dan pas de follow

Robins regel na zijn eigen verhuizing, en het log van beta bewijst hem:

[AP] outgoing Follow beta → ​https://soundfabrics.nl/ap/users/robo

(gated, awaiting guardians)

Beta is zelf een ward. Zijn UITGAANDE follow naar de verhuisde guardian werd
gepoort door §5.3, want op dat moment stond het nieuwe adres nog niet in zijn
guardian-lijst: handleMoveInbox werkte de relatie pas NA de follows bij. De
inkomende kant heeft precies hetzelfde: de ward gate't een Follow van een
onbekende, en de verhuisde guardian is op dat moment een onbekende.

Dus beide richtingen bleven hangen op een goedkeuring die niemand hoefde te geven,
omdat het om een guardian ging die er al was. Met de relatie eerst is de verhuisde
actor al erkend als de follows langskomen en gaat de auto-acceptatie door.

De volgorde is hier dus geen netheid maar de werking.

Changed files:
src/services/ActivityPubService.js

• het guardianship-blok staat nu VOOR de follow-lus, met het waarom erbij

test/move-guardianship.test.js

• test 5 meet de VOLGORDE, niet de uitkomst: hij leest de relatie uit binnen de injecteerbare followFn en eist dat die daar al op het nieuwe adres staat

remarks: de tegenproef is hier het punt. De vijf bestaande tests slagen ook met de
oude volgorde, want die kijken naar de eindtoestand. Met de guardianship-update er
wel in maar NA de follows valt alleen test 5 om. Suite 938 groen in UTC en
Europe/Amsterdam.

Dit is handmatig al rechtgezet voor beta en robo (relatie overgezet, follow opnieuw
gestuurd, beta's log gaat van "gated, awaiting guardians" naar "sig ok"). Deze commit
zorgt dat de volgende verhuizing die handmatige stap niet meer nodig heeft.

-robo
Co-Authored-By: Claude Opus 4.8 <noreply@…>

File:

• test/move-guardianship.test.js (modified) (1 diff)

test/move-guardianship.test.js

@@ -92 +92 @@
 });
 
+// De VOLGORDE, niet de uitkomst. De tests hierboven slagen ook als de relatie pas
+// na de follows wordt bijgewerkt, en juist dat ging mis bij Robins verhuizing:
+//
+//   [AP] outgoing Follow beta → .../robo (gated, awaiting guardians)
+//
+// Beta is zelf een ward, dus zijn uitgaande follow naar de verhuisde guardian werd
+// gepoort omdat het nieuwe adres nog niet in zijn guardian-lijst stond. Beide
+// richtingen bleven hangen op een goedkeuring die niemand hoefde te geven.
+test('de guardianship is al bijgewerkt VOORDAT de follow uitgaat', async () => {
+  let standTijdensFollow = null;
+  const stil = console.log; console.log = () => {};
+  try {
+    await AP.handleMoveInbox(move, {
+      ...stubs,
+      followFn: async () => {
+        // Op dit moment moet de gate aan de andere kant ons al kennen.
+        standTijdensFollow = db.prepare('SELECT other_uri FROM ap_guardianships').get().other_uri;
+        return true;
+      },
+    });
+  } finally { console.log = stil; }
+
+  assert.equal(standTijdensFollow, NIEUW,
+    'staat de relatie hier nog op het oude adres, dan gate\'t de ward de follow van zijn eigen guardian');
+});
+
 test('een Move naar een geblokkeerde bestemming verandert niets', async () => {
   db.prepare('INSERT INTO ap_blocks (slug, target, kind) VALUES (?,?,?)').run('voogd', NIEUW, 'actor');