mirrors/arti.git/crates/arti-rpcserver/src/msgs.rs, branch arti-v2.2.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v2.2.02026-01-12T19:14:19ZRemove a spurious debug_assert in arti-rpcserver.2026-01-12T19:14:19ZNick Mathewsonnickm@torproject.org2026-01-12T19:14:19Zurn:sha1:8dd6473630b7cca633e0006d1c3f5c4db4e8598a
This should never have been retained when we refactored our channels
for reporting responses into a single channel.
The bug became apparent when quicktest became derived from debug.
Fix name of clippy lint to unchecked_time_subtraction (2)2025-11-06T11:28:22ZIan Jacksonijackson@chiark.greenend.org.uk2025-11-06T11:23:25Zurn:sha1:a5fd5c48ea059a80cc1f6c50e248654b5ff3aaff
Run maint/add_warning
rpcserver: Increase coverage in msgs module2025-03-24T18:15:47Zvcrn3893-vcrn@gitlab.torproject.org2025-03-24T18:15:47Zurn:sha1:05ac14b8a23a0bb4a7dfcae01a93f779593616c8arti-rpcserver: Rename MethodNotFound to NoSuchMethod.2025-01-15T19:05:30ZNick Mathewsonnickm@torproject.org2025-01-15T19:03:31Zurn:sha1:71260de3ce35186a6e68fc10f0cae409258b4f80
Closes #1500.
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.)
Replace _ => panic!() elsewhere2024-10-15T11:14:10ZIan Jacksonijackson@chiark.greenend.org.uk2024-10-15T11:14:10Zurn:sha1:0f6eadfd9836b3507ad22a0bf4fae5749b8cf8b8arti-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.
arti-rpcserver: Correctly handle rpc.meta without `updates`2024-10-07T18:47:55ZNick Mathewsonnickm@torproject.org2024-10-07T18:47:55Zurn:sha1:b38a064b08a9d91586ab6e27ab57bdb81dc0d776
The `update` field in request.meta is optional, so we should allow
it to default to `false` when it is absent.
rpcserver: Remove TODO about optionality of params2024-10-07T17:28:43ZNick Mathewsonnickm@torproject.org2024-10-07T17:26:49Zurn:sha1:3f409bdc1726b91587081d27fc42da40645bb847
The spec no longer says that `params` is optional, so we can remove
the TODO about making it optional.
Closes #1665.
rpc: Simplify handling of fatal Json read errors.2024-09-16T17:17:14ZNick Mathewsonnickm@torproject.org2024-09-09T19:38:39Zurn:sha1:c13eaaea7fb939bebe13637536e146357267eb62
Previously, after determining that an error on an RPC connection
was fatal, we would:
1. Determine whether it was a "clean" close or one
that needed to be logged.
2. In exactly one case (specifically, when the inbound Json stream
contained a Value that was not an Object) , we would send back a
message to the client.
3. Exit the connection with Ok() or Err(e).
We no longer do step "2" above.
Additionally, we document:
- Why it's important to exit immediately on syntax errors.
- A better way to tolerate non-Object Json Values,
if we decide someday to do so.
Closes #1591.