| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
tor-circmgr: take_action: Handle Cancelled from the oneshot
Closes #365
See merge request tpo/core/arti!363
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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<Option<circ>, crate::Error>`.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
don't return already errored pending circuit when searching new circuit matching spec
Closes #210
See merge request tpo/core/arti!366
|
| | |/
| |
| |
| | |
matching spec
|
| | | |
|
| |/
|
|
|
|
|
|
| |
I wanted this while debugging something.
The ad-hoc impl Debug with f.debug_struct is getting repetitive
and I've already perpetrated one copy-paste mistake.
We should consider using something like the `educe` crate's Clone.
|
| |\ |
|
| | |
| |
| |
| |
| |
| | |
To implement this, we had to refactor the tor_circmgr api for
flushing state changes to disk, so that it checks if it has the lock,
and only then tries to store.
|
| | |
| |
| |
| | |
Also add some TODO comments in circmgr for future work.
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
Remove clippy::needless_borrow exception in CI.
Closes #310
See merge request tpo/core/arti!338
|
| | |
| |
| |
| |
| | |
This exception is no longer necessary now that the underlying CI bug
is fixed.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/
|
|
| |
This reduces our nesting, and will help us handle panics.
|
| |\ |
|
| | | |
|
| | |
| |
| |
| | |
We can't use discriminants here now, but maybe we can in the future.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| | |
(Instead of reporting the _last_ error, report the _worst_ error.)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| | |
There are a couple of tricky ones I'll do separately.
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
| |
In one of the two places, nightly no longer warns. In the other
place, it's fine for nightly to warn: I just fixed the code to take
a slice instead.
Partial revert of 856aca879151c622512bc4b15c6307808fc83e82.
Resolves part of #310.
|
| | |
|
| |
|
|
| |
Closes #338.
|
| |
|
|
|
|
| |
This edge-case was there even before the migration of
595fe1ab881b94106649, but now it's more explicit and ought to be
revisited.
|
| | |
|
| | |
|
| |
|
|
|
| |
(By our convention, these errors should say what we were trying to
spawn when the error occurred.)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Provide an enum variant to contain the SpawnError and a From impl.
We use `#[from]` here because it doesn't really make sense to attach
any context, as it's not likely to be very relevant.
|
| |
|
|
| |
Doing this here makes it easier when I rebase/reorder things
|
| |
|
|
| |
This will be used for error handling, and perhaps other things.
|
| |
|
|
|
|
|
|
| |
The type annotation may not be necessary for inference, but as a
comment it risks becoming false. So it should be uncommented, or
deleted.
Error types round here are not entirely trivial so uncomment it.
|
| |\
| |
| |
| |
| | |
dir-client: bug fix and more tests
See merge request tpo/core/arti!271
|
| | |
| |
| |
| |
| | |
Earlier versions have a bug in UnboundedReceiver that make our new
dirclient tests fail.
|
| |\ \
| | |
| | |
| | |
| | | |
Fix typos
See merge request tpo/core/arti!285
|
| | |/ |
|
| | | |
|
| |/
|
|
|
|
| |
Prompted by clippy::needless_question_mark. Sometimes Ok(r?) is
needed to do automatic error conversion. I assume the lint checks for
that. Anyway, in these cases it's not needed.
|
| |
|
|
|
|
|
|
| |
tor-netdir needs to bump because tor-netdoc bumped, even though
there were no other changes in tor-netdir. Whoops.
tor-guardmgr needs to bump because it already published, with the
older tor-netdir.
|