mirrors/arti.git/crates/arti-rpcserver/src/connection.rs, branch arti-v1.3.1mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.3.12024-10-24T01:35:05Zrpc: Tweak release_owned to give an error on second removal of "connection".2024-10-24T01:35:05ZNick Mathewsonnickm@torproject.org2024-10-24T00:48:42Zurn:sha1:270234f81c3a2fc5f56fbe3d71cabad672237a78rpc: Use a const for the "connection" object ID.2024-10-24T01:35:05ZNick Mathewsonnickm@torproject.org2024-10-24T00:44:08Zurn:sha1:797a9d21dd856e62a0525130d34d5a992b7f9a7crpc: Simplify method-dispatch-bypass logic a bit2024-10-24T01:35:05ZNick Mathewsonnickm@torproject.org2024-10-24T00:33:55Zurn:sha1:eb1d9acd10c5d500f56d637a7bba3acdd67dc9e8
This commit removes the separate function for asking whether to
bypass the dispatch code. Instead, it gives the "invoke with
bypass" function an error to return when no dispatch is warranted,
and moves the whole responsibility for method dispatch or
non-dispatch back into tor-rpcbase.
I had to add an ObjectId argument to `invoke_rpc_method` to make
this work, but that's probably a good thing.
Additionally, this commit tweaks the derive-deftly macro to prevent
you from asking for dispatch bypass on special methods, where it
isn't implemented (and doesn't really make sense).
rpc: Add support for dropping the special "connection" object ID.2024-10-24T01:35:05ZNick Mathewsonnickm@torproject.org2024-10-22T15:04:02Zurn:sha1:babc2f95d000499df4b8845fe2703d1270204505rpcserver: detect and use methods that bypass method dispatch.2024-10-24T01:35:05ZNick Mathewsonnickm@torproject.org2024-10-22T13:56:22Zurn:sha1:ec018b52e930c6c90e8fdd5d0a2a4853655fb7a1rpc: List missing required features in error data2024-10-17T23:49:13ZNick Mathewsonnickm@torproject.org2024-10-17T23:44:15Zurn:sha1:c20ce6e09b3a060ec7c7ac67a895161c4209189c
Our spec says that when the RPC client has said "I require you to have
feature X" and we don't have it, we need to include the feature(s)
we don't have in an `rpc:unsupported_features` field of our error.
Also, add an integration test for this behavior.
Closes #1662
Remove Rpc* variants from tor_error::ErrorKind2024-10-17T23:16:58ZNick Mathewsonnickm@torproject.org2024-10-16T18:58:58Zurn:sha1:5219f4cee5a74c0abdd8ad548b4ead9e2066cb2c
These are not regular ErrorKinds, since they can never occur in an
error that's meant to be returned from a Rust API like
`arti-client`. Instead, they only exist for errors returned from
RpcError.
(I can't find the place where we discussed this previously, but the
rationale is that if an ErrorKind never makes sense in response to
something that the user does from Rust, we should never have that be
an ErrorKind. The fact that the removed kinds do not actually
appear outside the RPC system suggests that this is reasonable.)
Use mpsc_channel_no_memquota in the RPC system (adding a TODO)2024-10-15T10:58:25ZIan Jacksonijackson@chiark.greenend.org.uk2024-10-09T18:39:33Zurn:sha1:377225ce8a1ab14b42714d0cc7174ff11504054a
We need to decide whether RPC will participate in memquota.
Perhaps it should. But that's for the future.
arti-rpcserver: minimal handling for request.meta.require2024-10-07T18:49:13ZNick Mathewsonnickm@torproject.org2024-10-07T18:49:13Zurn:sha1:849552a43f02615bff0c48496008694eba482bb2
We have defined a forward-compatibility mechanism for the RPC
system, where a request may list one or more required "features",
and if any feature is absent, the request will fail.
Since no "features" are currently implemented,
this code does the bare minimum to implement this mechanism,
by rejecting every request with a nonempty "require" field.
rpc: clarify documentation and fix typos2024-10-02T17:57:52ZNick Mathewsonnickm@torproject.org2024-10-02T17:57:52Zurn:sha1:3429bead88579892affd9886f93c7a512a80c786
Based on review from @opara.