feat(ocap-kernel): implement distributed garbage collection protocol #814
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
Coverage Report
File Coverage
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
grypez
reviewed
Feb 6, 2026
| const crankResult = await remote.deliverBringOutYourDead(); | ||
| expect(mockRemoteComms.sendRemoteMessage).toHaveBeenCalledWith( | ||
| mockRemotePeerId, | ||
| expect.any(String), |
Contributor
There was a problem hiding this comment.
Maybe worth us writing a plugin like expect.serialized({ key: value }).
FUDCo
previously approved these changes
Feb 6, 2026
Contributor
FUDCo
left a comment
FUDCo
left a comment
There was a problem hiding this comment.
Remarkable how much of this just consisted of renaming things. Very nice.
…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 <[email protected]>
Move the #remoteGcRequested in-memory state change after the savepoint commit, consistent with the transactional message processing pattern from #811. Also consolidate test assertions to use toStrictEqual on parsed objects per project convention, and fix return value expectation. Co-Authored-By: Claude Opus 4.6 <[email protected]>
Contributor
Author
|
sirtimid
force-pushed
the
sirtimid/remote-comms-dgc
branch
from
7f4aeac to
dba940f
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
FUDCo
approved these changes
Feb 9, 2026
Contributor
FUDCo
left a comment
FUDCo
left a comment
There was a problem hiding this comment.
Latest update seems to do exactly what was promised in the TODO comment :-)
I think the issue that Cursor Bugbot flagged is real, so if you need to do another turn of changes to address that, I'm happy to do another quick review round after.
FUDCo
previously approved these changes
Feb 9, 2026
Contributor
FUDCo
left a comment
FUDCo
left a comment
There was a problem hiding this comment.
Latest update seems to do exactly what was promised in the TODO comment :-)
I think the issue that Cursor Bugbot flagged is real, so if you need to do another turn of changes to address that, I'm happy to do another quick review round after.
…d store cache
The DGC e2e tests had two compounding bugs: they called scheduleReap('r0')
but the first allocated remote is r1, and they used a separate KernelStore
instance whose cache was isolated from the kernel's internal store.
Add reapRemotes() to RemoteManager and Kernel (mirroring reapVats) and
use it in the e2e tests instead of bypassing the kernel with an external
store. Remove getGCActions() and nextRemoteId assertions that suffered
from the same stale cache issue.
Also reset #remoteGcRequested flag in handlePeerRestart() so BOYD is
correctly sent to a new incarnation after peer restart.
Co-Authored-By: Claude Opus 4.6 <[email protected]>
sirtimid
force-pushed
the
sirtimid/remote-comms-dgc
branch
from
5297c39 to
2e895a7
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #779
Summary
Implements the DGC (Distributed Garbage Collection) protocol for remote kernel communication (Issue #779).
deliverBringOutYourDead()onRemoteHandlenow sends a['bringOutYourDead']wire message to the remote kernel instead of being a no-op#remoteGcRequested) prevents infinite BOYD loops between kernelsChanges
GC store widening (
gc.ts,garbage-collection.ts):scheduleReapto acceptEndpointId(union ofVatId | RemoteId) instead of justVatIdaddGCActionsandprocessGCActionSetto useinsistEndpointIdinstead ofinsistVatIdvatId/actionsByVattoendpointId/actionsByEndpointfor clarityBOYD protocol (
RemoteHandle.ts):BringOutYourDeadDeliveryto theDeliveryParamsunion typedeliverBringOutYourDead()to send BOYD over the wire via#sendRemoteCommand'bringOutYourDead'case to#handleRemoteDeliverthat callsscheduleReap#remoteGcRequestedflag: set after the savepoint commit (consistent with the transactional message processing pattern from Complete Ken protocol implementation #811), when BOYD was triggered by an incoming remote request the subsequent local BOYD is suppressedTests:
Test plan
🤖 Generated with Claude Code
Note
Medium Risk
Adds a new cross-kernel
bringOutYourDeadcontrol message and widens GC scheduling from vats to all endpoints, which can affect remote message flow and garbage-collection behavior if mis-triggered, but changes are mostly additive and well-covered by new unit/e2e tests.Overview
Implements distributed garbage collection across kernels by turning
RemoteHandle.deliverBringOutYourDead()into a real wire-leveldelivermessage (['bringOutYourDead']) that causes the receiving kernel toscheduleReapits remote endpoint and run GC, with a#remoteGcRequestedflag to prevent infinite BOYD ping-pong and to reset on peer restart.Widens GC plumbing from vat-only to endpoint-wide operation by treating GC actions and reap scheduling as
EndpointId(vat or remote) rather thanVatId, and addsKernel.reapRemotes()/RemoteManager.reapRemotes()debugging/test hooks to trigger remote reaping.Adds extensive coverage: new RemoteHandle unit tests for BOYD send/receive, seq/ack/persistence, ping-pong prevention, RemoteManager tests for reap scheduling, GC store tests for remote endpoint IDs, and nodejs e2e scenarios validating BOYD exchange and continued bidirectional messaging after DGC.
Written by Cursor Bugbot for commit ae4b9cc. This will update automatically on new commits. Configure here.