test_get_appointment fails when the plugin is asked about a given tracker before the
tower is able to process the appointment to tracker transition. This doesn't happen consistently,
but we've seen the error popping up every now and then.
Simply add a log based waiting to make sure the state transition is performed before asserting.
The re-register logic had a bug where the `TowerSummary` that was kept in memory
after re-registering was sweeping the references to both the pending and invalid appointments.
While this data was still in the database, re-registering may have made it look like the data was not there.
- Updates `Retrier::run` to return more meaningful errors. `Retrier::run` used to simply return a message,
revamps it to return RetryError variants so we can handle return cases better.
- Adds an additional state to `RetrierStatus`: Idle. Retries that fail due to an accumulation of transient errors will be flagged
as Idle instead of Failed and retried later on (based on `auto_retry_delay`). Notice Retrier data is not kept in memory while a retrier is Idle. Instead, data is cleared and loaded again from the database when the `Retrier` is ready to run again.
- Revamps how revocation data is sent to the `RetryManager`: The RetrierManager used to received locators one by one via unreachable_towers. This is due to them being mainly fed by `on_commitment_revocation`, which generates them one by one. However, both when manually retrying or when bootstrapping from an already populated database, multiple appointments may be pending for the same tower, hence needing to call `unreachable_towers.send` multiple times for the same tower. This itself was not a big deal, given we didn't really needed to differentiate between the cases. We do now though.
In order to implement periodic retries while allowing manual retries we need to be able to signal the state transition to the
`Retrier` without providing any new data:
- If a Retrier is idle and we receive data trough `on_commitment_revocation` we need to append that data to the `Retrier`.
- If a Retrier is iddle and we receive data trough a manual retry, we need to change the state of the `Retrier` without
adding any new data to it.
In order to implement this we've added an additional map to `WTClient` that reports the state of the active retriers. Retriers are active only if they are running or idle.
- Also reworks `WTClient::set_tower_status` to update the status only if the new one does not match the old one.
This is simply to reduce the boiler plate of having to perform this check in other pats of the plugin codebase.
`TeosD` outputDir was being set to the same directory use by the test suite.
That cause it to be logging in the same log file, potentially colluding for
read/write operations. Setting the outputDir to it's own location fixed the issue.
Replaces time.sleep in the `watchtower-plugin` tests to wait for certain things to happen
on the backend by wait_for_logs, which should be less error prone
Also does some reformating and removes unnecessary imports
Using --locked with cargo install(s) will instruct cargo to use the lock file in the repo (Cargo.lock).
So all the users' builds will be identical to builds in the master branch.
Signed-off-by: Omer Yacine <mariocynicys@gmail.com>
Traffic routed trough Tor was being redirected to localhost indistinguishably of whether
the public http API was being offered there or not. This made the tower unavailable
(trough Tor) when it was being offered both in clearnet and Tor.
In order to fix#130 we need to implement our own txindex. Turns out this is almost identical
to our `LocatorCache`, so we can generalize it and use it for both purposes.
