8000 Log error at HTTP response close by dentiny · Pull Request #9 · git-lfs-fuse/git-lfs-fuse · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Log error at HTTP response close #9

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

Merged
merged 1 commit into from
Apr 21, 2025

Conversation

dentiny
Copy link
Contributor
@dentiny dentiny commented Apr 21, 2025

I understand we don't want to (and it's not easy to) propagate error at function return, but at least we could log it out for easier debugging if something goes wrong.

@rueian rueian merged commit 0dcce9b into git-lfs-fuse:main Apr 21, 2025
@rueian
Copy link
Member
rueian commented Apr 21, 2025

Thanks, @dentiny. We log errors while reading the response body, but we don’t really care about errors that occur when closing the body. Do you have any experience suggesting that they can be helpful?

@dentiny
Copy link
Contributor Author
dentiny commented Apr 21, 2025

Thanks, @dentiny. We log errors while reading the response body, but we don’t really care about errors that occur when closing the body. Do you have any experience suggesting that they can be helpful?

My general practice is don't ignore error in all cases; logging, propagation, crash are all strictly better than ignore.
In this particular case, we read from response body and discard; if the read operation fails somehow, connection cannot be reused and could lead to unexpected performance degradation.

@rueian
Copy link
Member
rueian commented Apr 21, 2025

if the read operation fails somehow, connection cannot be reused and could lead to unexpected performance degradation.

And how can that log be helpful in this case?

@dentiny
Copy link
Contributor Author
dentiny commented Apr 21, 2025

And how can that log be helpful in this case?

According to the USE method, error logging is one of the items we need to check first. The logging here helps people understand what was going wrong in the system.

@rueian
Copy link
Member
rueian commented Apr 21, 2025

According to the USE method, error logging is one of the items we need to check first.

It doesn't talk about application logs, but instead talk about metrics provided by the operation system. Those metrics are indeed a better source for monitoring TCP efficiency, including reconnections.

The logging here helps people understand what was going wrong in the system.

Aren't the error logs while reading the response body enough? Here:

n, err := io.Copy(w, resp.Body)

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

Successfully merging this pull request may close these issues.

2 participants
0