| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| | |
|
| |
|
|
|
|
|
| |
Now, instead of telling the session or the connection to drop the
object ID, we tell the object ID to go away.
Closes #1663.
|
| | |
|
| |
|
|
|
| |
If and when we implement this, it will likely be different;
arti#868 has some thoughts on the implications.
|
| |
|
|
|
| |
These will have different implementations soon; this is a more
logical place for them.
|
| |\
| |
| |
| |
| | |
Fix typo in arti-rpcserver auth.rs comment
See merge request tpo/core/arti!2558
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.)
|
| |/
|
|
|
|
|
|
|
| |
I'm about to remove HasKind from InvokeError, which would otherwise
break this code.
These errors are all in fact internal errors, since in this context
they can only stem from incorrectly formed calls to
`invoke_special_method`.
|
| |\
| |
| |
| |
| |
| |
| | |
Use clippy to prevent non-mq use of mpsc::channel
Closes #1659
See merge request tpo/core/arti!2536
|
| | |
| |
| |
| |
| | |
We need to decide whether RPC will participate in memquota.
Perhaps it should. But that's for the future.
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
The `update` field in request.meta is optional, so we should allow
it to default to `false` when it is absent.
|
| |
|
|
|
|
|
| |
The spec no longer says that `params` is optional, so we can remove
the TODO about making it optional.
Closes #1665.
|
| |
|
|
| |
Based on review from @opara.
|
| |
|
|
|
|
| |
Previous documentation was more-or-less meant for the Arti developer
only. This new documentation is intended for actual users of RPC
functionality. It's meant to be extracted with `maint/rpc-doc-tool`.
|
| |
|
|
|
|
|
|
|
|
| |
Calling it "singleton" might have suggested that it was using the
[singleton pattern](https://en.wikipedia.org/wiki/Singleton_pattern),
which it isn't.
(Renaming done with rust-analyzer and double-checked with `git grep`.)
Closes #1585.
|
| | |
|
| |
|
|
|
|
| |
I've used an `async{ expr }.await` pattern, to make sure that
_every_ error returned by the `loop{select!{}}` construct is
actually transformed.
|
| |
|
|
| |
(This will make the next commit easier to read.)
|
| | |
|
| |
|
|
| |
Per suggestion from @diziet.
|
| |
|
|
|
|
| |
Instead of classifying errors and complicating our behavior _early_
in our loop, instead we just decide whether an error indicates an
EOF immediately before we return it.
|
| |
|
|
|
|
| |
Make it more clear than the previous match statement
that once we get an Err() from request_stream.next(),
we aren't going to continue the loop.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having this in the `tor-async-utils` crate prevents us from doing both
of the following without introducing a circular dependency:
* using it in `tor-rtmock` (which we currently do, particularly in
tests).
* using `tor-rtmock` to test things in `tor-async-utils`. We don't do
this yet, but it is generally sensible to do so. In particular we
want to move the `stream_peak` module there, which is currently tested
with `tor-rtmock`.
Moving this into its own crate avoids this circular dependency.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Unlike generational-arena, slotmap is maintained.
Unlike slotmap, slotmap-careful should never be able to reuse the
same key for two different objects.
Closes #1282.
|
| |\
| |
| |
| |
| |
| |
| | |
rpcserver: use more sophisticated handling for ConnectionError.
Closes #1517
See merge request tpo/core/arti!2335
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In general, we don't want to return a ConnectionError for a simple
EOF condition; we only want to report an error when there's an
actual failure.
Also, it's a good idea to capture the actual error return conditions
that we get from aynchronous_codecs, rather than throwing them away
as we did before.
Closes #1517.
|
| |/ |
|
| |
|
|
|
| |
(This will either become used later, or we will remove it;
the TODO RPC will remind us.)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Per discussion, this field isn't really specified in a way that lets
us fill it sensibly at the moment. So for now, we're going to just
omit it.
Additionally, we said that we'd Report on our errors; this branch
changes the implementation of RpcError to do that.
Question: Will the blanket implementation for Into<RpcError> make
it harder to re-add a Data field later on if we want to do so?
|
| |
|
|
|
| |
It is no longer necessary to say, for every RPC method,
that its error type is RpcError.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
On its own, this might not seem like a huge improvement, but it will
later let us implement these RPC methods for types that can't
reasonably implement ClientConnectionTarget.
It also serves as a proof of concept that special-method invocation
can actually work, so that we can build things like this in cases
where introducing a trait isn't practical.
Closes #1427
|
| |
|
|
| |
The context will make it possible to invoke rpc methods.
|
| |
|
|
|
|
|
|
|
|
|
| |
This lets us get rid of a now-spurious `RequestContext` wrapper type
and an extra layer of indirection; it will also make it easier to
treat a Connection _as_ a context, so that we can have a context in
the socks-rpc interface code.
This patch removes a TODO about "treading carefully" when we make
this change. When I added that TODO, I had misremembered some
implementation details of the RPC object system.
|
| |
|
|
| |
This will allow us to implement rpc::Context on Connection directly.
|
| | |
|
