Skip to content
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

ResponseLogHook is not called if error is nil #87

Open
tarasmatsyk opened this issue Mar 27, 2020 · 2 comments
Open

ResponseLogHook is not called if error is nil #87

tarasmatsyk opened this issue Mar 27, 2020 · 2 comments

Comments

@tarasmatsyk
Copy link

tarasmatsyk commented Mar 27, 2020

From what I understood you are calling log hook only if response is present, which makes sense. However hooks in my perspective is something called regardless of whether response is successful or not. For sure I can use checkRetry feature to get notified when response is returned, but maybe it would be possible to add something like OnErrorLogHook to ensure http.Do is fully wrapped?

here is a piece of code I am referring to:
https://github.com/hashicorp/go-retryablehttp/blob/master/client.go#L523

Let me know if this makes sense, I can add go with a PR

@tarasmatsyk tarasmatsyk changed the title ResponseLogHook is not called if response is err ResponseLogHook is not called if response is nil Mar 27, 2020
@jefferai
Copy link
Member

jefferai commented Apr 6, 2020

ResponseLogHook is actually called below that line and is called so long as err is not nil, not if response is not nil.

@tarasmatsyk tarasmatsyk changed the title ResponseLogHook is not called if response is nil ResponseLogHook is not called if error is nil Apr 6, 2020
@tarasmatsyk
Copy link
Author

Nice catch! That's what I was trying to say, However hooks in my perspective is something called regardless of whether response is successful or not.

Do you think it makes sense to let users catch errors if any? I mean, it really could be helpful to know that response is finished even with error as checkRetry seems to be a wrong place for this kind of functionality.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants