| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
|
| | | |
| | |
| | |
| | | |
IMO this is rather less confusing.
|
| | | |
| | |
| | |
| | | |
The two call sites become clearer, IMO.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
We're going to use these in a moment.
One returns entries and the other statuses simply because that's
what's actually going to be wanted.
|
| | |/
| |
| |
| |
| | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/587#note_2815945
|
| |/ |
|
| |\
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |\ \
| | |
| | |
| | |
| | | |
Use impl_standard_builder more and remove manual Default/builder impls
See merge request tpo/core/arti!594
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\| |
| | |
| | |
| | |
| | |
| | |
| | | |
Config handling and logging fixes
Closes #480
See merge request tpo/core/arti!589
|
| | |/
| |
| |
| |
| | |
Without this, if the substructure is provided, these fields are
mandatory within it.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Add "full" and "experimental" features to arti, arti-client, and below.
Closes #499
See merge request tpo/core/arti!584
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The "full" feature is a catch-all for all features, _except_:
* Those that select a particular implementation (like
tor-llcrypto/with-openssl) or build flag (like "static")
* Those that are experimental or unstable (like "experimental-api")
* Those that are testing-only.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is apparently a new warning from clippy nightly, documented in
https://rust-lang.github.io/rust-clippy/master/index.html#significant_drop_in_scrutinee .
I'm not in love with the temporary variables that this warning wants
me to introduce, but it does seem like a decent way to avoid some
kinds of deadlock.
|
| | |/
|/| |
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
Use TaskSchedule to sleep in directory bootstrapping
Closes #497
See merge request tpo/core/arti!571
|
| | | |
|
| | |
| |
| |
| |
| | |
This will allow somebody else to call bootstrap() if bootstrap() fails
the first time.
|
| | |
| |
| |
| |
| |
| | |
This change also means that we need to create the handle and scheduler
earlier in the process of creating the DirMgr. If we don't, we won't
have a way to manage the task before bootstrap() returns.
|
| | |
| |
| |
| |
| |
| | |
This change (not yet exposed as an API) will let the TorClient have
a `TaskHandle` corresponding to the directory task, letting it
make the directory task dormant as needed.
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This only affects uses of thread_rng(), and affects them all more or
less indiscriminately. One test does not work with
ARTI_TEST_PRNG=deterministic; the next commit will fix it.
|
| | |/
|/| |
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
lints: Make lint blocks consistent and ensure they stay that way
Closes #469
See merge request tpo/core/arti!557
|
| | |
| |
| |
| |
| | |
From running add_warning, with manual picking of the right
hunks/lines.
|
| | |
| |
| |
| |
| |
| | |
This was the result of:
maint/add_warning crates/*/src/{lib,main}.rs
and then manually curating the results.
|
| |/
|
|
|
|
| |
This was upposed to be one day, I presume!
Also complete a truncated sentence in the docs.
|
| |
|
|
|
|
| |
Utilize cargo-sort: https://github.com/DevinR528/cargo-sort
Signed-off-by: Orhun Parmaksız <[email protected]>
|
| |
|
|
|
|
|
| |
This commit was made by reverting the previous commit, then
re-running the script I used to generate it. In theory there should
be no semantic changes: only changes due to improved formatting from
cargo edit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I followed the following procedure to make these changes:
* I used maint/changed_crates to find out which crates had changed
since 0.3.0.
* I used grep and maint/list_crates to sort those crates in
topological (dependency) order.
* I looked through semver_status to find which crates were listed as
having semver-relevant changes (new APIs and breaking changes).
* I scanned through the git logs of the crates with no
semver-relevant changes listed to confirm that, indeed, they had
no changes. For those crates, I incremented their patch-level
version _without_ changing the version that other crates depend on.
* I scanned through the git logs of the crates with no
semver-relevant changes listed to confirm that, indeed, they had
no obvious breaking changes.
* I treated all crates that depend on `arti` and/or `arti-client` as
having breaking changes.
* I identified crates that depend on crates that have changed, even
if they have not changed themselves, and identified them as having
a non-breaking change.
* For all of the crates, I used `cargo set-version -p $CRATE --bump
$STATUS` (where `STATUS` is `patch` or `minor`) to update the
versions, and the depended-upon versions.
|
| |
|
|
|
|
|
|
| |
Now that the relevant functions now report changed/not-changed
status via a boolean out-parameter (see !527), there's no reason to
have a separate NoChanged error case.
Closes #484.
|
| |\
| |
| |
| |
| |
| |
| | |
DirMgr: Stop load-from-cache process when there is no change.
Closes #482
See merge request tpo/core/arti!527
|