mirrors/arti.git/crates/tor-rpcbase/src/dispatch.rs, branch arti-v1.3.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.3.02024-10-24T01:35:05Zrpc: 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).
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.)
rpc: Expose a delegation table in arti:x_list_all_rpc_methods2024-09-24T14:45:51ZNick Mathewsonnickm@torproject.org2024-09-16T14:54:27Zurn:sha1:438407b6b335b984ce84b4f65ac0b3cd7ec99aa2
Closes #1624.
rpc: add mandatory delegate-type attribute to Object template2024-09-24T14:45:51ZNick Mathewsonnickm@torproject.org2024-09-16T14:29:30Zurn:sha1:0c7fc748144c8a6b80ce422e6c0055dc1497285e
When specifying a delegation, the template user must also say what
type they're delegating to.
We're going to use this to document and expose delegations.
Fix typos2024-09-03T08:09:02ZDimitris Apostoloudimitris.apostolou@icloud.com2024-09-03T08:09:02Zurn:sha1:676f913463b7d84f34dd6101b99d03ef79cf57adrpcbase: Implement RPC method delegation support.2024-08-14T15:52:36ZNick Mathewsonnickm@torproject.org2024-08-14T15:52:36Zurn:sha1:3d18a0b83556dada0279f2dd6681d81391e57177
(Couldn't use Deref here, since we needed to get an Arc.)
Only one delegation target per object is permitted for now.
This will help with #1523.
rpcbase: Feature to list the RPC methods and what they apply to.2024-08-13T00:27:03ZNick Mathewsonnickm@torproject.org2024-08-12T16:02:22Zurn:sha1:89543b0010f550a5699293d7b3f07752971be6a4rpcbase: Facility for looking up RPC method information2024-08-13T00:19:20ZNick Mathewsonnickm@torproject.org2024-08-12T14:09:54Zurn:sha1:5883a585d74e2e95a13fd804b3281f72dd57525b
We'll need this to refer to the names of RPC methods as visible to
the caller, and to cross-reference them with their related types.
rpcbase: Expose Invocable type names directly.2024-08-12T13:57:36ZNick Mathewsonnickm@torproject.org2024-08-12T13:57:36Zurn:sha1:f976408e0f208679154577e511723cecaacb6b00
Previously, we exposed them only via `describe_invocable`, which
would have required the caller to parse a string in order to find
these.
rpc: Refactor errors part 1: a new RpcMethod trait.2024-07-25T12:43:30ZNick Mathewsonnickm@torproject.org2024-07-23T17:23:58Zurn:sha1:c7c630c44d9e937d7185f591d75fd42c33ab5238
It is no longer necessary to say, for every RPC method,
that its error type is RpcError.