| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
| |
| |
| |
| | |
(This function behaves as `futures::sink::SinkExt::with`, except
that the function that it takes does not return a future.)
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
This lets us do much less in our rpc_invoke_fn functions.
|
| |/
|
|
|
| |
Now `Method` has an Output and Update associated type, and
`decl_method` can do a little more.
|
| |\
| |
| |
| |
| | |
Followups from !1145
See merge request tpo/core/arti!1146
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Otherwise there is too much risk of accidentally adding in another
1<<12 when we meant to add a 1<<13.
(It would be neat to have an alternative to bitflags here that would
auto-number our bitflags for us.)
|
| | |
| |
| |
| | |
Clarify that it isn't anything that most users will need to check.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
A few RPC refactorings
Closes #817 and #824
See merge request tpo/core/arti!1144
|
| | | |
| | |
| | |
| | |
| | | |
Previously we have two places where we had to do "make a `Drain` sink
if updates aren't wanted"; now there's only one.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously the main loop received updates via a `mpsc::channel`, and
final responses via a `futures::unordered`. This could lead to
final responses being transmitted to the user before the updates
were all flushed.
Now all of the responses are sent to the main loop via the same channel,
and they can't get out-of-sequence.
Closes #817 and (IMO) simplifies the code a bit.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Now that the sink is not part of the context, RPC functions that are
able to send an update have to declare an `impl Sink` as their
fourth argument. This syntax is not final.
Part of #824.
|
| | | |
| | |
| | |
| | |
| | | |
Now the update sink is its own boxed object. It is not yet passed
to the invoke functions that want it.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
rpc spec: define method namespacing.
Closes #822
See merge request tpo/core/arti!1141
|
| | | | |
| | | |
| | | |
| | | | |
Closes #822
|
| |\ \ \ \
| |_|_|/
|/| | |
| | | |
| | | |
| | | |
| | | | |
DirMgr: Detect that directory state is ready if it begins with all MDs
Closes #802
See merge request tpo/core/arti!1126
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously, we'd only call PendingNetDir::upgrade_if_necesessary
when adding a microdescriptor. But if it began already having all
of its descriptors (because we found them in the cache), we wouldn't
actually upgrade it to a PendingNetDir::Yielding, which would make
it unusable, and would make us schedule its reset time too far
in the future.
Fixes #802.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
netdoc: Add MiddleOnly flag to RelayFlags
Closes #833
See merge request tpo/core/arti!1145
|
| |/ / / /
| | | |
| | | |
| | | | |
Closes #833
|
| |\ \ \ \
| |_|_|/
|/| | |
| | | |
| | | | |
rpcserver: Fix a couple of broken rustdoc links
See merge request tpo/core/arti!1143
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
fix macos reproducible builds
Closes #832
See merge request tpo/core/arti!1142
|
| |/ / / |
|
| |\ \ \
| |_|/
|/| |
| | |
| | | |
Run cargo update
See merge request tpo/core/arti!1140
|
| |/ /
| |
| |
| |
| | |
The lockfile on main seems to be broken. I skim-eyeballed the diff,
which is entirely autogenerated.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Update our secmem_proc dependency to 0.3.0
Closes #664
See merge request tpo/core/arti!1138
|
| | | |
| | |
| | |
| | |
| | |
| | | |
(This wasn't possible before we updated our MSRV to 1.65.)
Closes #664.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Upgrade a couple more dependencies
See merge request tpo/core/arti!1139
|
| | | | | |
|
| | |/ / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
RPC: Terminology and error-handling conformance
Closes #826 and #825
See merge request tpo/core/arti!1136
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Now instead of hoping that buggy clients will detect a magic `id`,
we can simply tell them that they will get no `id` at all. If they
can't handle that case, no major harm is done: the connection will
get closed anyway.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Since we're serializing everything in this format, let's enforce it.
With this change, we can no longer cram arbitrary junk into an
RPC error, so we have to clean up our handling of cancelled requests.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is a bit big, but it's not that _complicated_.
The idea here is that we use serde's "untagged" enum facility
when parsing our `Request`s, such that if parsing as a `Request`
fails, we parse as an `InvalidRequest` and try to report
what the problem was exactly.
This lets us determine the ID of a request (if it had one),
so we can report that ID in our error message. We can also
recover from a much broader variety of errors.
We now also conform with the spec reporting errors about
completely wrong json, requests without IDs, and so on.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Well, mostly correct. Our current serde implementation doesn't
tell us much about what went wrong with the object, so we can't
tell why we couldn't convert it into a Request.
Also, our output for the data field is not as the spec says:
we should bring them into conformance.
Part of #825.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
These are experimental for now so that we can change them without
breaking semver.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
The field is called "kinds", it is a list, and it holds strings
beginning with "arti:".
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Even though json-rpc uses "result" to mean "a successful return value
from a method", we can't: Rust's `Result` type is so pervasive
that confusion would be inevitable.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Always "method", never "command".
Always "authentication scheme", never "authentication method".
|