New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider changing interface of internal send_request
function
#47
Comments
Previously, we relied on the wallet in the `monero-wallet-rpc` daemon to be loaded as we do on startup. As a consequence of this expectation, restarting `monero-wallet-rpc` to fix bugs like #652 resulted in the ASB no longer operating correctly. To fix this, we now load the wallet on-demand in case the daemon responds with the error code -13. Ideally, we would implement this behaviour generically using the proxy pattern on the `MoneroWalletRpc` trait. Unfortunately, when attempting to do so we uncover a limitation in the design of `jsonrpc_client`. This limitation is tracked in thomaseizinger/rust-jsonrpc-client#47. Once fixed, we can implement this logic in a more robust way that is not tied to the `check_tx_key` RPC call but applies to any RPC call automatically.
Previously, we relied on the wallet in the `monero-wallet-rpc` daemon to be loaded as we do on startup. As a consequence of this expectation, restarting `monero-wallet-rpc` to fix bugs like #652 resulted in the ASB no longer operating correctly. To fix this, we now load the wallet on-demand in case the daemon responds with the error code -13. Ideally, we would implement this behaviour generically using the proxy pattern on the `MoneroWalletRpc` trait. Unfortunately, when attempting to do so we uncover a limitation in the design of `jsonrpc_client`. This limitation is tracked in thomaseizinger/rust-jsonrpc-client#47. Once fixed, we can implement this logic in a more robust way that is not tied to the `check_tx_key` RPC call but applies to any RPC call automatically.
Previously, we relied on the wallet in the `monero-wallet-rpc` daemon to be loaded as we do on startup. As a consequence of this expectation, restarting `monero-wallet-rpc` to fix bugs like #652 resulted in the ASB no longer operating correctly. To fix this, we now load the wallet on-demand in case the daemon responds with the error code -13. Ideally, we would implement this behaviour generically using the proxy pattern on the `MoneroWalletRpc` trait. Unfortunately, when attempting to do so we uncover a limitation in the design of `jsonrpc_client`. This limitation is tracked in thomaseizinger/rust-jsonrpc-client#47. Once fixed, we can implement this logic in a more robust way that is not tied to the `check_tx_key` RPC call but applies to any RPC call automatically.
Regarding this issue, shouldn't the #[async_trait::async_trait]
pub trait SendRequest: 'static
{
type Error: StdError;
async fn send_request<P>(
&self,
endpoint: Url,
body: String,
) -> Result<Response<P>, Error<Self::Error>>
where
P: DeserializeOwned;
} Where the impl<T> From<T> for crate::Error<T> {
fn from(inner: T) -> Self {
crate::Error::Client(inner)
}
} With this, we would:
Or, another take would be that maybe parsing the json response should be handled by the caller, replacing the #[async_trait::async_trait]
pub trait SendRequest: 'static
{
type Error: StdError;
async fn send_request(
&self,
endpoint: Url,
body: String,
) -> Result<String, Self::Error>
} While keeping the |
Feel free to give the first one a shot, I don't remember whether I just didn't try this or if there are any issues why it doesn't work! Happy to discuss over a draft PR as well 😊 |
Previously, we relied on the wallet in the `monero-wallet-rpc` daemon to be loaded as we do on startup. As a consequence of this expectation, restarting `monero-wallet-rpc` to fix bugs like #652 resulted in the ASB no longer operating correctly. To fix this, we now load the wallet on-demand in case the daemon responds with the error code -13. Ideally, we would implement this behaviour generically using the proxy pattern on the `MoneroWalletRpc` trait. Unfortunately, when attempting to do so we uncover a limitation in the design of `jsonrpc_client`. This limitation is tracked in thomaseizinger/rust-jsonrpc-client#47. Once fixed, we can implement this logic in a more robust way that is not tied to the `check_tx_key` RPC call but applies to any RPC call automatically.
One of the design goals of this client is to allow for easy generation of proxies by implementing the trait yourself and forwarding to an inner implementation.
At the moment, this doesn't work quite well because the generated
send_request
function doesn't do the parsing of the response and hence anyone overwriting that function cannot access stuff like theJsonRpcError
.The text was updated successfully, but these errors were encountered: