mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.2.0 2022-03-21T13:06:32Z 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. 2022-02-17T17:22:51Z Nick Mathewson nickm@torproject.org 2022-02-17T17:22:51Z urn:sha1:de86ac0b0f8eda0c3045cc7e7e77381165e38851 2022-02-17T17:12:04Z Nick Mathewson nickm@torproject.org 2022-02-17T17:05:33Z urn:sha1:4db586cf007b7965013287abea2b9ab88a0d03c6 We can't use discriminants here now, but maybe we can in the future. 2022-02-16T19:35:06Z Nick Mathewson nickm@torproject.org 2022-02-16T19:27:25Z urn:sha1:543916e81254ba76dc8975f6195b73db9f6b58ed From its old name, this error had implied that we were giving no useful information when we were waiting on a pending cirucit request that failed. In fact, this error would only happen if we dropped the `mpsc::Sender` for a circuit attempt without reporting success or failure. 2022-02-16T19:35:06Z Nick Mathewson nickm@torproject.org 2022-02-16T19:16:39Z urn:sha1:1d773e748f6bb90c7ba46e79a6254e0a9d1103d4 (Instead of reporting the _last_ error, report the _worst_ error.) 2022-02-16T19:35:06Z Nick Mathewson nickm@torproject.org 2022-02-16T18:04:13Z urn:sha1:c1899f787bd5eb3513b1d1c5661d90e8498874b9 These errors should almost never be seen by the user; we should instead retry the circuit. But they _can_ be seen by the use if selecting a guard takes too long, or too many attempts. (Therefore, they aren't true "internal" errors.) I suspect that we might not want to keep this TransientFailure kind, but I'm not sure what else to do here for now. 2022-02-16T19:35:06Z Nick Mathewson nickm@torproject.org 2022-02-16T17:52:32Z urn:sha1:96d856e2640011a7aeb0c5ecef4d787e0fb9b610 There are a couple of tricky ones I'll do separately.