mirrors/arti.git/crates/tor-circmgr/src/timeouts/pareto.rs, branch arti-v1.5.0 mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.5.0 2025-08-13T16:12:28Z tor-circmgr: Make connection failure log at debug level. 2025-08-13T16:12:28Z Wesley Aptekar-Cassels me@wesleyac.com 2025-08-13T16:12:28Z urn:sha1:a1970a6f64cf6393b0763e529c73194aa484a7fb tor-circmgr: Add more logging about timeout estimation. 2025-08-12T15:25:01Z Wesley Aptekar-Cassels me@wesleyac.com 2025-08-11T23:54:07Z urn:sha1:51b689af344d3f24375c66a05f8feb1449d86f1c We're seeing the logic that resets the timeouts when 18/20 connections fail not triggering when we're expecting it to, this logging may help figure out what's going on there. Switch Cargo.toml files to edition 2024. 2025-08-07T15:28:36Z Nick Mathewson nickm@torproject.org 2025-08-06T01:19:58Z urn:sha1:77b0de43b8c67cdb81befe0680a3df43b6ad37bc First, run ``` git grep -l "^edition =" | xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;' ``` Second, manually verify that all Cargo.toml files have changed, and nothing else has changed. Third, run cargo fmt again. Resolve clippy warnings from 1.83 2025-05-13T18:53:41Z Nick Mathewson nickm@torproject.org 2025-05-13T18:53:41Z urn:sha1:b182a9d05902bc5320ab486d055521f18b6b7832 Now that our MSRV is 1.83, clippy is happy to make more recommendations for us. tor-circmgr: Explicit type annotation 2025-03-26T09:51:19Z Clara Engler cve@cve.cx 2025-03-25T14:52:23Z urn:sha1:b5c44d2be580ea73fd71aad01b19dbf4d88d8b72 This commit adds an explicit type annotation to the learning_timeouts() function, as leaving it out yielded an error while trying to compile tor-circmgr in a project that had this crate deep down in its supply chain. circmgr: test behavior of IteratorRandom::choose_multiple 2025-03-25T12:05:56Z Nick Mathewson nickm@torproject.org 2025-03-24T12:09:12Z urn:sha1:295deff2a416870b5af9d6cbd3246a991cd10652 Merge branch 'timeout_est_overflow' into 'main' 2025-03-19T17:52:22Z Nick Mathewson nickm@torproject.org 2025-03-19T17:52:22Z urn:sha1:ab18f0ee711834b836f2613e3cdc46ecd5e9f125 Impose a maximum on our fallback estimated timeout Closes #1693 See merge request tpo/core/arti!2842 squash! Upgrade rand dependency to 0.9. 2025-03-18T16:09:44Z Nick Mathewson nickm@torproject.org 2025-03-18T13:01:31Z urn:sha1:2f8993c22c2b86010e4fd8b5169ef0ab83f8c754 - `rand::thread_rng()` has been deprecated and renamed to `rand::rng()` Impose a maximum on our fallback estimated timeout 2025-03-06T16:28:58Z Nick Mathewson nickm@torproject.org 2025-03-06T16:28:58Z urn:sha1:0359fafa89c6bdcbffb9315eef2372730411702d The fallback timeout is the one that we use when we have insufficient data. We reset our observations, and maybe rebuild our circuits, when we find that too many circuits have failed recently. When we do so, we double our fallback timeout. Previously we had no limit, which could lead to overflow (#1693). In this commit we impose a maximum of 2 hours, which is ridiculously high. (C tor uses a maximum of INT32_MAX seconds, which is even more ridiculously high.) Closes #1693. tor-circmgr: Add trace log on circuit build timeout. 2025-01-08T19:15:40Z Wesley Aptekar-Cassels me@wesleyac.com 2025-01-08T19:15:40Z urn:sha1:b22d41eda02f1da9e7b05aea09ebd2ce1f5966dc This may help debugging #1792.