mirrors/arti.git/crates/tor-chanmgr/src, branch arti-v1.3.1mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.3.12024-11-27T19:11:58Ztor-chanmgr: remove immediately awaited async block expression2024-11-27T19:11:58ZSteven Engleropara@torproject.org2024-11-26T20:17:59Zurn:sha1:278a678c1f3cd36bdc805df439f01cde6dfa02f6
This shouldn't be needed anymore now that we use a `Defer`.
tor-chanmgr: use `Defer` in `AbstractChanMgr` to handle cancellations2024-11-27T19:10:41ZSteven Engleropara@torproject.org2024-11-26T20:13:24Zurn:sha1:935176f245e711fe270d86010c310e6c0a0410c4tor-chanmgr: add `util::defer` module2024-11-27T19:09:22ZSteven Engleropara@torproject.org2024-11-26T20:11:14Zurn:sha1:d9c150b4a604ad23b98be82b00f718720265e11a
This contains the `Defer` type, which can be used to defer a closure
until the `Defer` is dropped.
tor-chanmgr: change `RequestCancelled` retry from `Never` to `Immediate`2024-11-21T18:35:57ZSteven Engleropara@torproject.org2024-11-21T18:29:26Zurn:sha1:f6f33ef982263aa2db981e87a3657e35b9c0c730
If the channel request was cancelled, we should be able to retry
immediately. Additionally, the `kind()` of `RequestCancelled` is
`TransientFailure`, and I don't think it make sense for a transient
error to return a `retry_time()` of `Never`.
tor-chanmgr: fix reconfigure bug when given `CheckAllOrNothing`2024-11-12T23:48:36ZSteven Engleropara@torproject.org2024-11-05T22:00:55Zurn:sha1:d7de30057914067faeee2bf8619661f11f3ad086
We shouldn't actually reconfigure anything if given `CheckAllOrNothing`.
tor-chanmgr: remove panics in debug builds2024-11-12T01:27:27ZSteven Engleropara@torproject.org2024-11-12T01:23:04Zurn:sha1:cad2a7288bfb71b456e1f7690349cf721c421872
These were supposed to fail loudly in debug builds by panicking, but
panics are mostly useless for debugging in async applications that use a
runtime which catches panics. So we'll just log the error instead.
tor-chanmgr: rename `replace_pending_channel` to `upgrade_pending_channel_to_open`2024-10-24T18:08:19ZSteven Engleropara@torproject.org2024-10-21T17:02:20Zurn:sha1:aba584022de282cba738fd57ef80f335f2f15b34tor-chanmgr: `remove_pending` now takes a `PendingChannelHandle`2024-10-24T18:07:44ZSteven Engleropara@torproject.org2024-10-21T16:58:32Zurn:sha1:5020d1502ed00e06017d6e9d1a1704dad36224f1tor-chanmgr: improve cleanup procedure of pending channels2024-10-24T18:07:44ZSteven Engleropara@torproject.org2024-10-21T15:36:45Zurn:sha1:d1e90447a24460d4991033c198bedff20dc855c4
An attempt to make sure that there are no code paths which forget to
remove a pending channel from the channel map.
This also adds error-level log messages and panics during debug builds
if a `PendingChannelHandle` is dropped without properly passing it to
`MgrState::remove_pending_channel` or
`MgrState::replace_pending_channel`.
Revert "tor-chanmgr: `PendingChannelHandle` removes the channel when dropped"2024-10-21T15:40:41ZSteven Engleropara@torproject.org2024-10-21T15:32:31Zurn:sha1:90083e81fad3c6497a43d6a1f1fb4f1bc3c378e4
This reverts commit f85bc3cf849109aaa2c4da9fc8c06e7173a0543f.
There were some small conflcits in
`AbstractChanMgr::get_or_launch_internal`, so this wasn't a clean
revert.