Conversation
Is it the only advantage? I assume that you're creating strategy using initial clients and then if disconnect occurs, loop is able to recover and your strategy isn't, right? Then imo the simplest way is to impl struct SharedSourceClient {
shared_data: Arc<Mutex<SharedSourceClientData>>,
}
struct SharedSourceClientData {
substrate_client: relay_substrate_client::Client<YourChain>,
}
impl RelayClient for SharedSourceClient {
fn reconnect() {
self.shared_data.lock().await.client.reconnect();
}
}Then you may simply return errors from your strategy and loop will do a reconnect. If you have other usages for this |
|
Yes, The purpose of adding this method is to get the client. I will try the method your suggestion. |
Bumps [log](https://github.com/rust-lang/log) from 0.4.16 to 0.4.17. - [Release notes](https://github.com/rust-lang/log/releases) - [Changelog](https://github.com/rust-lang/log/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/log/commits/0.4.17) --- updated-dependencies: - dependency-name: log dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
In this way, a healthy original client can be obtained, Only use
Anyto return, because there is norelay-client-substratepackage dependent on this library.This is not necessarily a good method, but it is indeed a solution.
After do that, If we create a customized relay strategy. we can get an original client from
relay_referenceIn doing so, the biggest advantage is that third-party applications can get a client that will not lose the connection, because this has been processed in the message-lane-loop .