Skip to content

feat(ocap-kernel): implement distributed garbage collection protocol#814

Open
sirtimid wants to merge 1 commit intomainfrom
sirtimid/remote-comms-dgc
Open

feat(ocap-kernel): implement distributed garbage collection protocol#814
sirtimid wants to merge 1 commit intomainfrom
sirtimid/remote-comms-dgc

Conversation

@sirtimid
Copy link
Contributor

@sirtimid sirtimid commented Feb 6, 2026

Summary

Implements the DGC (Distributed Garbage Collection) protocol for remote kernel communication (Issue #779).

  • deliverBringOutYourDead() on RemoteHandle now sends a ['bringOutYourDead'] wire message to the remote kernel instead of being a no-op
  • The remote kernel schedules a local reap, runs GC, and sends back drops/retires
  • A ping-pong prevention flag (#remoteGcRequested) prevents infinite BOYD loops between kernels

Changes

GC store widening (gc.ts, garbage-collection.ts):

  • Widen scheduleReap to accept EndpointId (union of VatId | RemoteId) instead of just VatId
  • Update addGCActions and processGCActionSet to use insistEndpointId instead of insistVatId
  • Rename internal variables from vatId/actionsByVat to endpointId/actionsByEndpoint for clarity

BOYD protocol (RemoteHandle.ts):

  • Add BringOutYourDeadDelivery to the DeliveryParams union type
  • Implement deliverBringOutYourDead() to send BOYD over the wire via #sendRemoteCommand
  • Add 'bringOutYourDead' case to #handleRemoteDeliver that sets the ping-pong prevention flag and calls scheduleReap
  • Add #remoteGcRequested flag: when BOYD was triggered by an incoming remote request, the subsequent local BOYD is suppressed

Tests:

  • Unit tests for GC with remote endpoints and reap scheduling
  • Unit tests for BOYD send/receive, ping-pong prevention, seq/ack tracking, and persistence
  • E2E tests for distributed GC across two kernels via libp2p

Collision note

This PR will have merge conflicts with #811 in RemoteHandle.ts and RemoteHandle.test.ts. After merging #811, the #remoteGcRequested = true assignment should be moved after the savepoint commit (marked with a TODO comment).

Test plan

  • All ocap-kernel unit tests pass (1800+)
  • All nodejs e2e tests pass (35)
  • All extension e2e tests pass (19)
  • CI passes

🤖 Generated with Claude Code


Note

Medium Risk
Touches kernel remote messaging and GC scheduling logic, so regressions could impact cross-kernel connectivity or object lifecycle; changes are well-covered by new unit and E2E tests but involve protocol/state-machine behavior.

Overview
Implements distributed GC across kernels by making RemoteHandle.deliverBringOutYourDead() send a real ['bringOutYourDead'] wire delivery and by handling incoming BOYD deliveries by scheduling a local reap; a #remoteGcRequested flag suppresses echo BOYD to prevent infinite ping-pong.

Widens GC plumbing from vat-only to generic EndpointId (vat or remote): GC actions parsing/validation and processGCActionSet now group/process by endpoint, and scheduleReap accepts remote IDs. Adds/updates unit and E2E coverage to verify BOYD send/receive behavior (including seq/ack + persistence), remote reap scheduling, and end-to-end DGC completion without breaking connectivity.

Written by Cursor Bugbot for commit 7f4aeac. This will update automatically on new commits. Configure here.

…779)

Implement the DGC protocol so that `deliverBringOutYourDead()` on a
RemoteHandle sends a BOYD wire message to the remote kernel, which
schedules a local reap, runs GC, and sends back drops/retires.

- Widen `scheduleReap` to accept `EndpointId` (vat or remote)
- Update GC action parsing to use `insistEndpointId`
- Add `bringOutYourDead` delivery type to RemoteHandle
- Add ping-pong prevention flag to avoid infinite BOYD loops
- Add unit tests for BOYD protocol and GC endpoint widening
- Add e2e tests for distributed GC in remote-comms

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@github-actions
Copy link
Contributor

github-actions bot commented Feb 6, 2026

Coverage Report

Status Category Percentage Covered / Total
🔵 Lines 78.16%
⬆️ +0.02%
6097 / 7800
🔵 Statements 78.13%
⬆️ +0.03%
6195 / 7929
🔵 Functions 76.57%
🟰 ±0%
1559 / 2036
🔵 Branches 78.4%
⬆️ +0.02%
2226 / 2839
File Coverage
File Stmts Branches Functions Lines Uncovered Lines
Changed Files
packages/ocap-kernel/src/garbage-collection/garbage-collection.ts 98.24%
🟰 ±0%
93.33%
🟰 ±0%
100%
🟰 ±0%
98.24%
🟰 ±0%
76
packages/ocap-kernel/src/remotes/kernel/RemoteHandle.ts 84.92%
⬆️ +0.50%
82.35%
⬆️ +0.65%
84.44%
🟰 ±0%
85.6%
⬆️ +0.48%
347, 366-427, 462, 501, 508-510, 551-564, 920
packages/ocap-kernel/src/store/methods/gc.ts 89.74%
🟰 ±0%
68.18%
🟰 ±0%
100%
🟰 ±0%
89.74%
🟰 ±0%
140, 153, 179-186, 202
Generated in workflow #3593 for commit 7f4aeac by the Vitest Coverage Report Action

@sirtimid sirtimid marked this pull request as ready for review February 6, 2026 16:23
@sirtimid sirtimid requested a review from a team as a code owner February 6, 2026 16:23
Copy link
Contributor

@grypez grypez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upgrades from vat gc -> endpoint gc

LGTM, but probably @FUDCo should look, too. The ping-pong prevention works for two kernels; is there a case of three kernels that can get BOYD-locked?

const crankResult = await remote.deliverBringOutYourDead();
expect(mockRemoteComms.sendRemoteMessage).toHaveBeenCalledWith(
mockRemotePeerId,
expect.any(String),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe worth us writing a plugin like expect.serialized({ key: value }).

Comment on lines +168 to +170
expect(parsed.seq).toBe(1);
expect(parsed.method).toBe('deliver');
expect(parsed.params).toStrictEqual(['bringOutYourDead']);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the root CLAUDE.md:

  • If testing all properties of an object, use a single toStrictEqual() on the entire object instead of multiple expect() calls

@grypez grypez requested a review from FUDCo February 6, 2026 21:58
Copy link
Contributor

@FUDCo FUDCo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remarkable how much of this just consisted of renaming things. Very nice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants