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://d.iamgay.cn/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]>
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 queuing/notification timing by deferring sends, promise notifications, and kernel subscription callbacks until crank commit. Bugs here could drop or reorder outputs, or alter promise-resolution side effects across local/remote paths.
Overview
Makes cranks transactional by buffering vat outputs.
KernelQueuenow supports bufferedenqueueSend/enqueueNotifyand a buffered mode forresolvePromises, flushing buffered run-queue items only after a successful crank and discarding them on rollback.Promise-resolution side effects are deferred to commit.
resolveKernelPromiseno longer enqueues run-queue sends directly; it returns queued messages soKernelQueuecan buffer/enqueue them consistently, and kernel-level promise subscription callbacks are invoked during buffer flush rather than immediately.Updates
KernelStoreto maintain a per-crank output buffer (cleared on rollback/reset), adjusts vat syscalls to use buffered mode, and refreshes tests/docs to reflect the new crank-buffering model and remaining Ken-protocol gaps.Written by Cursor Bugbot for commit d2d6c52. This will update automatically on new commits. Configure here.