Include latest error in AllAttemptsErrored

[nabijaczleweli]

$ git grep AllAttemptsErrored
src/client.rs:                        return Err(Error::AllAttemptsErrored(errors));
src/client.rs:                                        return Err(Error::AllAttemptsErrored(errors));

fixed here

src/raw_client.rs:    Err(Error::AllAttemptsErrored(errors))

already correctly collected

src/types.rs:    AllAttemptsErrored(Vec<Error>),
src/types.rs:            Error::AllAttemptsErrored(errors) => {

consumers

Closes #186

[ValuedMammal]

Concept ACK, however you still have unwrap in your code which isn't great. Maybe it will be better to log the warning first before placing the error into the errors vec.

[nabijaczleweli]

Updated, how's about now?

[ValuedMammal]

In 59c28bd: Include latest error in AllAttemptsErrored

I understand that we can expect errors to be non-empty after pushing an error into it, however this code is dangerous and error prone due to the unchecked container access. The only time e is used outside of the errors vector is to pass a reference to the warn! macro, so it'd arguably be better to log the warning first before moving the value into errors. This is the suggestion I tried to convey in an earlier comment #188 (review).

Please also include a PR description that others can make sense of, and consider using conventional commits. Thanks for your contribution. @nabijaczleweli

[nabijaczleweli]

Sure, whatever; applied.

You're free to rephrase the PR and commit descriptions as you see fit, from my POV "Include latest error in AllAttemptsErrored" follows all the relevant conventions and is human-readable.

[ValuedMammal]

I had an additional comment related to the order of the logging statements. I think I would prefer this way, so that in the case of a failed attempt the latest error e can still be captured by the logs. Let me know what you think. @nabijaczleweli

--- a/src/client.rs
+++ b/src/client.rs
@@ -55,16 +55,15 @@ macro_rules! impl_inner_call {
                 Err(e) => {
                     let failed_attempts = errors.len() + 1;
 
+                    warn!("call '{}' failed with {}, retry: {}/{}", stringify!($name), e, failed_attempts, $self.config.retry());
+
+                    errors.push(e);
+
                     if retries_exhausted(failed_attempts, $self.config.retry()) {
                         warn!("call '{}' failed after {} attempts", stringify!($name), failed_attempts);
-                        errors.push(e);
                         return Err(Error::AllAttemptsErrored(errors));
                     }
 
-                    warn!("call '{}' failed with {}, retry: {}/{}", stringify!($name), e, failed_attempts, $self.config.retry());
-
-                    errors.push(e);
-
                     // Only one thread will try to recreate the client getting the write lock,
                     // other eventual threads will get Err and will block at the beginning of
                     // previous loop when trying to read()
@@ -80,15 +79,14 @@ macro_rules! impl_inner_call {
                                 Err(e) => {
                                     let failed_attempts = errors.len() + 1;
 
+                                    warn!("re-creating client failed with {}, retry: {}/{}", e, failed_attempts, $self.config.retry());
+
+                                    errors.push(e);
+
                                     if retries_exhausted(failed_attempts, $self.config.retry()) {
                                         warn!("re-creating client failed after {} attempts", failed_attempts);
-                                        errors.push(e);
                                         return Err(Error::AllAttemptsErrored(errors));
                                     }
-
-                                    warn!("re-creating client failed with {}, retry: {}/{}", e, failed_attempts, $self.config.retry());
-
-                                    errors.push(e);
                                 }
                             }
                         }

[nabijaczleweli]

I think this is a functional change (which I naturally wouldn't do unless otherwise directed), but I do prefer this order. Applied.