| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The important thing here is that we need to look up the object
_after_ we invoke any non-dispatched methods, since the object might
be an expired weak reference.
This required some related changes to tests and error types.
Additionally, it required us to change the return value of
Context::remove, since we can remove objects that are not completely
present.
|
| | |
|
| | |
|
| |
|
|
| |
This makes it a little easier to drop unwanted capabilities.
|
| |
|
|
|
| |
The Connection will know the options that the listener was created
with, as opposed to RpcMgr, which is the same for every listener.
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Edited-by: Nick Mathewson <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| |
|
|
| |
Other parts of the crate no longer look at the .0 field directly.
|
| |\
| |
| |
| |
| | |
rpc: Move support for weak references behind an experimental feature
See merge request tpo/core/arti!2742
|
| | |
| |
| |
| |
| | |
We haven't decided how these should work (see #868), so having them
present by default is a bad idea.
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The current cancel code is prone to deadlock, so the easiest way to
solve it appears to be making cancel requests themselves
uncancellable.
I've included a test to verify the behavior; previously, this test
caused a deadlock.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Closes #1753
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.)
|
| |
|
|
|
| |
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.
|
| |
|
|
| |
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`.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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 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.
|
| | |
|
| | |
|
