| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
Replace `base64` crate with `base64ct` crate in `tor-netdoc`
See merge request tpo/core/arti!600
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
These tests are borrowed from other parts of the `tor-netdoc`
crate.
|
| | | | |
| | | |
| | | |
| | | | |
Request for changes: `https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/600#note_2816252`
|
| | | | |
| | | |
| | | |
| | | | |
As per request, here: `https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/600#note_2816252`
|
| | | | | |
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | | |
Note: the `base64ct` crate rejects invalid characters when the
decoding is done on padded strings. However, the `FromStr` impl
for `B64` can have both padded **and** unpadded inputs, so all
inputs are now padded first, before decoding.
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
Error cleanup, part 1
See merge request tpo/core/arti!601
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
(The use of Cow<> in the error message isn't strictly necessary
here, but it's a pattern I want to encourage.)
|
| | | |
| | |
| | |
| | |
| | | |
Also note an issue with the design of tor-bytes::Error that should
probably go in a separate MR.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This is one I missed earlier.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
These changes make sure that the errors conform to our preferred
style, and include a description of what exactly we were doing when
something went wrong.
|
| |\| |
| | |
| | |
| | |
| | | |
Do not include error source() in display() format.
See merge request tpo/core/arti!598
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
According to doc/Errors.md, and in keeping with current best
practices, we should not include display an error's `source()` as
part of that error's display method. Instead, we should let the
caller decide to call source() and display that error in turn.
Part of #323.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Detect and report stalled directory downloads
Closes #468
See merge request tpo/core/arti!587
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
AttemptId is now linked to DirStatus in StatusEntry.
DirBootstrapStatus now has an inner enum to make invalid status
unrepresentable.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
I believe this type was made public in error: No other crate uses it,
and no API exposes it.
|
| | | | |
| | | |
| | | |
| | | | |
Closes #468.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The `DirBootstrapStatus` type now exposes a blockage() method to
return an `Option<DirBlockage>`.
The blockage types reported are more low-level than I'd like, but
they are IMO good enough for now: we'll want to get experience with
actual vs hypothetical problems before we refine them.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
If there was no partial information, then calling update_progress
will now report a stall in this case, which is not what we want.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
A "reset" happens whenever we have to start a download attempt over
-- either because we ran out of retries, or we found something wrong
with the consensus after fetching certificates.
An "error" happens when we have a recoverable error from one or more
directory sources.
A "stall" happens whenever a round of downloads or cache loads leads
to no change in the status.
We don't yet use this as part of our status reporting.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously we used the "if-modified-since" time associated with the
consensus download, and/or the "valid-after" time in the consensus
attempt, to put multiple attempts into sequence, and to tell one
from another. But that approach was always a kludge, and will soon
get more unreliable as the DirStatus logic gets a bit more complex.
With this commit, we change separate download attempts to be
identified with an AttemptId that increments whenever we decide to
get a different directory from the one we have. IMO this new code
is _much_ cleaner.
|
| | | | |
| | | |
| | | |
| | | | |
This is all crate-internal APIs, fortunately.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is about to become only a _part_ of what defines a DirStatus: a
DirStatus will also include a reset count, and some kind of info
about how long we've gone without progress.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
As per discussion in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/586#note_2813573
|
| | | | |
| | | |
| | | |
| | | | |
Consequential ordering changes.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/586#note_2814276
Change names and comments and docs everywhere.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/586#note_2813574
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Addresses
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/586#note_2813567
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
We need this because it is a type parameter for the types of nf_ito_*.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This lets a caller map the inner value, eg to convert the type.
I don't provide `map` as well as `try_map` now, since I don't need it;
we could add it later if it is desirable (although try_map can always
be used instead).
I was hoping to provide a `TryFrom` instead, but that necesasrily
overlaps with the std conversion impl from IntegerMilliseconds<T> to
IntegerMilliseconds<U> where T == U.
|
