feat: Add rpc-methods package
#474
Merged
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
|
Updated dependencies detected. Learn more about Socket for GitHub ↗︎
|
rekmarks
force-pushed
the
rekm/rpc-methods-package
branch
from
041f8bc to
5fe6aef
Compare
sirtimid
reviewed
Apr 7, 2025
- Add rpc-methods package for internal RPC calls - Consolidate PromiseCallbacks type into utils package
rekmarks
force-pushed
the
rekm/rpc-methods-package
branch
from
b231d66 to
505aed9
Compare
rekmarks
commented
Apr 8, 2025
Comment on lines
+132
to
+137
| { | ||
| files: ['**/test/**/*', '**/*.test.ts', '**/*.test.tsx'], | ||
| rules: { | ||
| '@typescript-eslint/explicit-function-return-type': 'off', | ||
| }, | ||
| }, |
Member
Author
There was a problem hiding this comment.
Incidental change: This is a common pattern in our tests that is completely fine.
5 tasks
rekmarks
added a commit
that referenced
this pull request
Apr 11, 2025
…#481) Progresses: #369 Continues the work of #369 by replacing the "vat worker" command / reply types with the pattern introduced in #474. This primarily affects the extension, since only its `VatWorkerManager` (so renamed from `VatWorkerService`) logically crosses process boundaries. Its Node.js counterpart is just a class that lives next to the kernel, and is only affected by some renamed types.
rekmarks
added a commit
that referenced
this pull request
Apr 22, 2025
…#487) Closes: #369 Replaces all kernel and vat "message" types with the new `RpcClient` / `RpcService` pattern. For related work and the justification for this, see: - #369 - #474 - #481 Note that, in the course of implementing this refactor, it was discovered that we are never returning _any_ responses to syscalls originating from vat supervisors. This PR maintains a provisional solution using the new pattern, and #488 tracks the work to actually fix this.
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.
Progresses: #369
Introduces a new package,
@ocap/rpc-methods, whose primary affordances are two:RpcClientandRpcService. These classes are intended to represent the call-er and call-ee ends of an RPC relationship. In brief, you:RpcClient.call()RpcService.execute()These two classes consume "method" and "handler" specifications. The idea is that you specify your methods individually, gather these specifications together into a "specification" or "handler" record, and then let the rest of your RPC types follow from there.
Our first target for this pattern is the "kernel control methods", where we are able to replace the
MessageResolverandCommandRegistryabstractions, as well as the hated request / response structs. Seepackages/extension/src/kernel-integration/handlersfor where most of this action occurred. Although this PR consists of equal amounts of additions and deletions, you'll note the kernel control method implementation in the extension is significantly simplified (+700 / -1300).The application's behavior should be virtually unaffected by this change. Following this PR, we will target other RPC channels in order to get rid of their request / response structs as well.