mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.5.0 2022-06-21T18:14:14Z 2022-06-21T18:14:14Z Nick Mathewson nickm@torproject.org 2022-06-21T18:14:14Z urn:sha1:08d9bbf33b9fff8aa33a823422aa4e323137be07 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. 2022-04-12T13:19:10Z Nick Mathewson nickm@torproject.org 2022-04-12T13:19:10Z urn:sha1:4582dddca8d5f301d6d68203c7309f292a68d8b5 Rather than running preemptive circuit construction every 10 seconds, we change it to back off when it is "failing". (We define "failing" as creating no new circuits, and as giving at least one error.) This change means that we'll have one less reason to hammer the network when our connectivity is failed for some reason. Closes #437. Part of #329. 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:32Z urn:sha1:c3b2bcc91e8c46b19bdacfed8a1f257d6882e835 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-21T13:06:32Z Nick Mathewson nickm@torproject.org 2022-03-18T15:57:39Z urn:sha1:d38aafa054a89d7e5217b48d9161d899d18553aa We already have the ability to get peer information from ChanMgr errors, and therefore from any RetryErrors that contain ChanMgr errors. This commit adds optional peer information to tor-proto errors, and a function to expose whatever peer information is available. 2022-03-21T13:06:32Z Nick Mathewson nickm@torproject.org 2022-03-16T18:15:29Z urn:sha1:451a53a5bfc8f8992d603f638956d144512cd70c If all guards are down and they won't be retriable for a while, try waiting that long to get whichever guard _is_ retriable. Additionally, if we are making multiple circuit plans in parallel, only report our planning as having failed if we failed at making _all_ the plans. Previously we treated any failure as fatal for the other plans, which could lead to trouble in the case when guards were all down or pending. Part of #407. 2022-02-22T20:30:12Z Nick Mathewson nickm@torproject.org 2022-02-22T20:30:12Z urn:sha1:04ca1f662f4d53726d888973e12261673da08b12 Also add some TODO comments in circmgr for future work. 2022-02-18T19:22:38Z Nick Mathewson nickm@torproject.org 2022-02-18T19:22:38Z urn:sha1:3ff9b187ea26aaec4875067fcdbf485ecc9f597d We handle them by reporting them to task that's waiting for the circuit, then relaying the panic. Doing so allows the waiting task to distinguish panics (EK::Internal) from cases where the reactor dropped the task entirely (EK::ReactorShuttingDown). And doing _that_ removes one case of EK::Canceled, which helps us on our goals towards #348. Closes #347.