feat(ocap-kernel): Buffer vat outputs to make cranks transactional #794
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
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
FUDCo
force-pushed
the
chip/crank-buffer
branch
from
556b89e to
844a8a4
Compare
Contributor
Coverage Report
File Coverage
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
FUDCo
force-pushed
the
chip/crank-buffer
branch
from
780c285 to
063ad3f
Compare
FUDCo
force-pushed
the
chip/crank-buffer
branch
from
063ad3f to
be19c83
Compare
This change makes kernel cranks fully transactional by buffering vat outputs (sends and notifications) during crank execution. On successful completion, the buffer is flushed to persist outputs. On rollback, the buffer is cleared without flushing. Key changes: - Add crank buffer to hold sends and notifications during crank - Modify enqueueSend/enqueueNotify to buffer instead of immediate persist - Modify resolvePromises to buffer notifications and defer kernel callbacks - resolveKernelPromise now returns queued messages for caller to buffer - Flush buffer in run() on successful crank completion - Clear buffer on rollback This ensures that network transmissions (via RemoteHandle) only happen after successful crank completion, supporting the Ken protocol's output validity guarantee. Closes #786 Co-Authored-By: Claude Opus 4.5 <[email protected]>
When enqueueMessage creates a result promise, it stores a JavaScript callback but doesn't add a kernel-level subscriber. When resolving such promises, no notify items were buffered, so the callback was never invoked at flush time. Fix by tracking promises with kernel subscriptions during resolve and invoking their callbacks at flush time, regardless of whether they have kernel-level subscribers. Co-Authored-By: Claude Opus 4.5 <[email protected]>
Remote message handling calls resolvePromises outside of crank execution. With the previous changes that always buffered outputs, the notifications and kernel subscriptions were never flushed because #flushCrankBuffer is only called in the main run() loop. This fix adds a buffer parameter (defaulting to false) to resolvePromises: - When buffer=true (vat syscalls), outputs are buffered for crank completion - When buffer=false (remote handling), outputs are processed immediately Co-Authored-By: Claude Opus 4.5 <[email protected]>
Rename the `buffer` parameter to `immediate` in enqueueSend, enqueueNotify, and resolvePromises, inverting the boolean sense: - immediate=true (default): process immediately - immediate=false: buffer for crank completion This naming is clearer since the parameter controls whether to act immediately rather than naming a buffer that doesn't exist as a parameter. Co-Authored-By: Claude Opus 4.5 <[email protected]>
FUDCo
force-pushed
the
chip/crank-buffer
branch
from
be19c83 to
5b53b35
Compare
Co-Authored-By: Claude Opus 4.5 <[email protected]>
sirtimid
reviewed
Jan 30, 2026
Co-Authored-By: Claude Opus 4.5 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
This change makes kernel cranks fully transactional by buffering vat outputs (sends and notifications) during crank execution. On successful completion, the buffer is flushed to persist outputs. On rollback, the buffer is cleared without flushing.
This ensures that network transmissions (via RemoteHandle) only happen after successful crank completion, supporting the Ken protocol's output validity guarantee.
Closes #786
Note
Medium Risk
Changes core kernel scheduling semantics by buffering vat-generated sends/notifications and deferring promise subscription callbacks until crank commit, which could impact message ordering, wakeups, and timing-sensitive logic despite test coverage.
Overview
Makes kernel cranks transactional by introducing a per-crank output buffer in
KernelStoreand routing vat syscalls (send,resolve, and resolved-subscribenotifications) through bufferedenqueueSend/enqueueNotifypaths.On successful crank completion
KernelQueue.run()now flushes buffered outputs into the run queue and only then invokes kernel promise subscription callbacks; on abort/rollback the buffer and any queued kernel-subscription invocations are discarded. Promise resolution is adjusted soresolveKernelPromise()returns queued messages for the caller to enqueue/buffer instead of directly enqueuing them.Updates tests accordingly and expands
docs/ken-protocol-assessment.mdto document the crank-buffering improvement and remaining gaps aroundRemoteHandledeferred network transmission.Written by Cursor Bugbot for commit 520cbe8. This will update automatically on new commits. Configure here.