-
Notifications
You must be signed in to change notification settings - Fork 64
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Revamps the cln-pugin to support retrying towers automatically
- 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.
- Loading branch information
Showing
3 changed files
with
534 additions
and
172 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.