This PR does some housekeeping & refactoring before tackling the issue.
Our settlement client logic was broken in 2 pieces, account creation and execution of the settlement. The first lived in the API crate while the second one lived in the Settlement crate.
This PR moves the account creation logic to the Settlement crate, and takes advantage of its retry-mechanism to add retry features to the send_settlement and send_message calls. This also allows us to finally remove the tokio-retry crate and with that the dependency on futures 0.1 compat.
The client also made sense to exist in the settlement::core module, as we want it to be consumed by other packages as well without them having to turn on the settlement_api feature.
Once that house keeping was done, the API Client was switched to use the one from interledger_settlement, and the action taken is: if negative settle_to is provided on account creation (or modification by the admin) -> execute settlement
Closes https://github.com/interledger-rs/interledger-rs/issues/591
This PR does some housekeeping & refactoring before tackling the issue.
Our settlement client logic was broken in 2 pieces, account creation and execution of the settlement. The first lived in the API crate while the second one lived in the Settlement crate.
This PR moves the account creation logic to the Settlement crate, and takes advantage of its retry-mechanism to add retry features to the
send_settlementandsend_messagecalls. This also allows us to finally remove the tokio-retry crate and with that the dependency on futures 0.1 compat.The client also made sense to exist in the
settlement::coremodule, as we want it to be consumed by other packages as well without them having to turn on thesettlement_apifeature.Once that house keeping was done, the API Client was switched to use the one from
interledger_settlement, and the action taken is: if negative settle_to is provided on account creation (or modification by the admin) -> execute settlement