-
Notifications
You must be signed in to change notification settings - Fork 2
fix: Retry updates #141
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
fix: Retry updates #141
Conversation
| where | ||
| F: Fn() -> Fut, | ||
| Fut: Future<Output = Result<T, RobustProviderError>>, | ||
| Fut: Future<Output = Result<T, RpcError<TransportErrorKind>>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reverting the change asked for in #135 (comment).
Why? Since we know we're working only with alloys providers, it is safe to specify the RpcError as the expected one for all operations.
| Err::<i32, RobustProviderError>(RobustProviderError::Timeout) | ||
| Err(TransportErrorKind::BackendGone.into()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Presumably Error::Timeout was returned for simplicity, but to avoid future confusion about this retry... timing out, better for the inner error to be something else.
| #[error("Retry failed after {0} tries")] | ||
| RetryFail(usize), | ||
| #[error("RPC call failed after exhausting all retry attempts: {0}")] | ||
| RetryFailure(Arc<RpcError<TransportErrorKind>>), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should be safe to assume that the lib user already knows the max retry count, so we should only notify them that retries have failed and with what error
Towards #112