Bump all crates to 0.1.0

2022-03-01T13:59:34Z

resolve comment

2022-02-28T19:05:17Z

add some error to retry_error instead of dropping it

2022-02-28T18:30:40Z

Merge branch 'teardown' into 'main'

2022-02-28T15:16:03Z

tor-circmgr: take_action: Handle Cancelled from the oneshot Closes #365 See merge request tpo/core/arti!363

Merge branch 'fix/210' into 'main'

2022-02-28T13:16:31Z

don't return already errored pending circuit when searching new circuit matching spec Closes #210 See merge request tpo/core/arti!366

Add a debug! log message for source cancellation

2022-02-28T12:52:38Z

Fix rustfmt

2022-02-28T12:36:48Z

Fix two typos

2022-02-28T11:21:52Z

don't return already errored pending circuit when searching new circuit matching spec

2022-02-27T12:16:03Z

tor-circmgr: take_action: Handle Cancelled from the oneshot

2022-02-25T18:10:36Z

Fixes #365 Inspection of the code and logs shows that: * One of the plan futures' oneshots must be returning Cancelled * This means that the corresponding sender must have been dropped * The sender is owned by the task spawned by spawn_launch Presumably that entire task gets dropped as part of executor shutdown, or something. The correct response in this situation is to declare that we are shutting down, and stop trying to do stuff. Unfortunately, despite trying quite hard by putting sleeps in various strategic places, I have not been able to reproduce the problem. So I can't be 100% sure that the new behaviour is correct. But I am reasonably confident that this ought not to be able to occur unless either 1. the task from spawn_launch is dropped, or 2. that task somehow panics despite its attempts to trap panics and report them as errors through the oneshot. So this "burn it all down" action ought only to occur in actually serious situations. I observe that 3ff9b187ea26aaec4875067fcdbf485ecc9f597d Handle panics from circuit construction. changed the EK for PendingCanceled to EK::ReactorShuttingDown, and there's From impl. I think, therefore, that it is right to reuse this Error variant. I don't quite understand why when take_action gets an actual error it doesn't push it, but just logs it. But I am not changing that for now. Arguably the two instances of retry_error.push are a sign of an inferior flow control pattern - maybe the loop body including the code I am adding ought to be an IEFE returning `Result, crate::Error>`.

mirrors/arti.git/crates/tor-circmgr, branch arti-v0.1.0