| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The execute_internal_ok method converts every error response into an
internal error; as such, it's only appropriate when there is no way
for a well-behaved Arti instance to give an error response.
But we had been using it in a few places where errors were possible
under other circumstances.
This commit fixes that behavior, and adds documentation to help
avoid it.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
rpc: Resolve a couple of dead code TODOs
See merge request tpo/core/arti!2731
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | | |
Fix several 'TODO RPC' notes in the arti crate.
See merge request tpo/core/arti!2737
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Formerly this was a conditional method argument, which is a huge
antipattern. Now it is unconditionally present, as `Option<T>` for
a type that is uninhabited when RPC isn't supported.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
rust-analyzer keeps re-wrapping this piece for me, even though
rustfmt doesn't complain.
|
| | | | |
| | | |
| | | |
| | | | |
Information _is_ passed to the RpcMgr, via the argument to new_connection.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
The RpcMgr does indirectly hold a reference to the client,
via its make_session argument.
|
| | | | |
| | | |
| | | |
| | | | |
We _do_ have error detection from this function, and have for ages.
|
| |/ / /
| | |
| | |
| | |
| | | |
This was necessary before we had support for implementing
RPC methods on generic types.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
tor-config: Improve mistrust documentation
See merge request tpo/core/arti!2727
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This commit improves the documentation for
`ConfigurationSources::set_mistrust`, by explaining that this option is
unrelated to the paths defined within the configuration file itself,
referring to the `storage.permissions.dangerously_trust_everyone`
option.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
arti-rpc-client-core: Use EmptyReply instead of EmptyResponse.
See merge request tpo/core/arti!2732
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | | |
It looks like !2729 and !2722 raced with each other, because we're still
using the old name for `EmptyReply` (and so `arti-rpc-client-core`
doesn't currently compile on `main`).
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | | |
rpc: Implement request cancellation
Closes #818
See merge request tpo/core/arti!2722
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Nothing used it, and it has some semantic complexity.
(see
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2722#note_3149591
)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The Waker::clone_from implementation uses Waker::will_wake
to avoid unnecessarily cloning a Waker that it already
has a copy of.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I hope that this limitation is acceptable;
the alternative involves some significant refactoring to give
Request a Weak reference to RpcConn -- but RpcConn isn't currently
kept in an Arc<> at all, and so we'd need some fairly heavy hacking.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Cancellation is now fallable, which allows us to detect attempts
to cancel which cannot work.
We now guarantee that when you try to cancel a `Cancel<F>` future,
either the cancel operation will succeed, or the future will return
(or will have already returned) Ok(), but not both, and not neither.
Closes #818.
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | | |
rpclib: Rename params/reply structs for consistency.
Closes #1586
See merge request tpo/core/arti!2729
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Our now convention here in rpclib is that a struct holding a
request's parameters is called `FooParams`, and a struct holding
that request's reply is called `FooReply`.
Closes #1586
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Better instructions for handling new MPL dependencies
See merge request tpo/core/arti!2726
|
| | | | | |
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Update `service-side-pow.md`
See merge request tpo/core/arti!2701
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Now that it's not in a Arc internally it shouldn't have this.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Per review feedback:
> We have discovered that as a general rule of thumb, it is a good idea
> to expose the `Arc`. This has a number of advantages; for example, if a
> caller wants a `Weak` for any reason, that's right there. The typical
> pattern is for the constructor to return `Arc<Self>` and methods to take
> `self: &Arc<Self>`.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is something we wanted to do in general for security reasons, and
ad I was implementing I discovered that it actually makes the code
simpler, rather than more complicated.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
These are needed to allow the PowManager to get the blinded ID needed to
construct a PoW verifier.
|
