mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=tor-dirmgr-v0.5.1 2022-06-13T13:26:32Z 2022-06-13T13:26:32Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-06-13T13:26:32Z urn:sha1:3e035927f20e88fa01f3b82649daa08551c4fda6 Run rustfmt. Separate commit to make review of the substantive commit easier. 2022-06-13T13:25:45Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-06-13T13:25:45Z urn:sha1:7d223ac9e6c6d998d51a2d66baaeddea086dca37 This is a *lot* of unwraps. The function takes no parameters and is used only for testing. It ought to be infallible. 2022-05-23T16:55:37Z Nick Mathewson nickm@torproject.org 2022-05-23T16:32:31Z urn:sha1:546ae3000eb179aedc97de30b0ccdb1d45b93395 It's a little overzealous sometimes, but it's mostly to the good. 2022-04-25T17:06:26Z Nick Mathewson nickm@torproject.org 2022-04-25T16:40:33Z urn:sha1:2f6bc6bdc431fa36de70a167eea777dcf3f60bf2 Remove all `use` statements for `TryFrom` and `TryInto`. These are now redundant in Rust 2021. 2022-04-12T12:41:32Z Nick Mathewson nickm@torproject.org 2022-04-12T12:41:32Z urn:sha1:3d5276a9cc6030751f9b4ff541c4055a4e66f75c This feature is similar to ChanProvenance from ChanMgr, except that we don't yet need to report it outside the crate. I'm going to use it to distinguish newly created circuits from existing circuits in the preemptive circuit builder. 2022-04-04T15:41:00Z Nick Mathewson nickm@torproject.org 2022-04-04T15:41:00Z urn:sha1:36440a957c762f2dfe43569a0545cbbda7f738a9 This lets us say that the UsageMismatch cases in some parts of the code reflect a programming error (RetryTime::Never), whereas in other case it reflects another circuit request getting to the circuit first (RetryTime::Immediate). 2022-04-04T15:15:18Z Nick Mathewson nickm@torproject.org 2022-03-31T19:41:38Z urn:sha1:6d8a6b42e7cc9737c3a93ff6a23aaaea11e45fbe Use the new RetryTime type and its associates to decide how long to wait (if at all) between attempts to build a circuit. Closes #421. Part of #329. 2022-04-04T15:15:18Z Nick Mathewson nickm@torproject.org 2022-03-31T19:17:02Z urn:sha1:f7810d42eb953bf57d9d777fc823087211350452 Previously we did not distinguish errors that came from pending circuits from errors that came from the circuits we were building. We also reported errors as coming from "Left" or "Right", instead of a more reasonable description. 2022-04-04T15:14:52Z Nick Mathewson nickm@torproject.org 2022-03-31T18:51:02Z urn:sha1:86c59dd1f337919023779ad92bb08ca79e876158 We were treating restrict_mut() failures as internal errors, and using internal errors to represent them. But in fact, these failures are entirely possible based on timing. Here's how it happens: * Two different circuit requests arrive at the same time, and both notice a pending circuit that they could use. * The pending circuit completes; both pending requests are notified. * The first request calls restrict_mut(), and restricts the request in such a way that the second couldn't use it. * The second request calls restrict_mut(), and gets a failure. Because of this issue, we treat these errors as transient failures and just wait for another circuit. Closes #427. (This is not a breaking API change, since `AbstractSpec` is a crate-private trait.) 2022-03-30T18:14:52Z Nick Mathewson nickm@torproject.org 2022-03-30T18:14:52Z urn:sha1:bd798764a47332393fd6b036093dba9c73770d79 Previously, if we had launch_parallelism > 1, and we were willing to retry building a circuit max_retries times, then we'd launch up to max_retries * launch_parallelism circuits before giving up. Ouch! With this patch, we try to keep the total number of circuits planned and attempted to the actual max_retries limit. Part of #329; found with arti-testing.