gin
gin copied to clipboard
Stop useless panicking in context and render
When user resets connection to the server, the go's http returns "broken pipe -> write tcp...". There is no needed to panicking because it's common case.
Instead of this I suggest to catch any errors, excepting broken pipe (syscall.EPIPE error), in server-side initialised logger.
This will improve overall performance of gin and will very helpful to log any other render errors to log.
Codecov Report
Merging #2150 (f32da2d) into master (3010cbd) will increase coverage by
0.00%
. The diff coverage is100.00%
.
@@ Coverage Diff @@
## master #2150 +/- ##
=======================================
Coverage 98.63% 98.63%
=======================================
Files 42 42
Lines 3140 3141 +1
=======================================
+ Hits 3097 3098 +1
Misses 29 29
Partials 14 14
Flag | Coverage Δ | |
---|---|---|
98.63% <100.00%> (+<0.01%) |
:arrow_up: | |
go-1.16 | ∅ <ø> (?) |
|
go-1.17 | 98.53% <100.00%> (+<0.01%) |
:arrow_up: |
go-1.18 | 98.53% <100.00%> (+<0.01%) |
:arrow_up: |
go-1.19 | 98.63% <100.00%> (+<0.01%) |
:arrow_up: |
macos-latest | 98.63% <100.00%> (+0.09%) |
:arrow_up: |
ubuntu-latest | 98.63% <100.00%> (+<0.01%) |
:arrow_up: |
Flags with carried forward coverage won't be shown. Click here to find out more.
Impacted Files | Coverage Δ | |
---|---|---|
context.go | 97.97% <100.00%> (+0.01%) |
:arrow_up: |
render/json.go | 82.75% <100.00%> (-0.39%) |
:arrow_down: |
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.
This PR close two issues: https://github.com/gin-gonic/gin/issues/1827 https://github.com/gin-gonic/gin/issues/1770
When user resets connection to the server, the go's http returns "broken pipe -> write tcp...". There is no needed to panicking because it's common case.
Instead of this I suggest to catch any errors, excepting broken pipe (syscall.EPIPE error), in server-side initialised logger.
This will improve overall performance of gin and will very helpful to log any other render errors to This processing method is very good. In 2019, I found that there was a problem with the panic processing here, which often led to the online service CPU full, abnormal service, and online failure. I also mentioned issue to gin in 2019, but it hasn't been solved. Now from your submission, it's really a great way to deal with it. I support this mode. Thank you very much
When user resets connection to the server, the go's http returns "broken pipe -> write tcp...". There is no needed to panicking because it's common case.
Instead of this I suggest to catch any errors, excepting broken pipe (syscall.EPIPE error), in server-side initialised logger.
This will improve overall performance of gin and will very helpful to log any other render errors to log.
This processing method is very good. In 2019, I found that there was a problem with the panic processing here, which often led to the online service CPU full, abnormal service, and online failure. I also mentioned issue to gin in 2019, but it hasn't been solved. Now from your submission, it's really a great way to deal with it. I support this mode. Thank you very much!
Is there any update of this PR?
This will also close https://github.com/gin-gonic/gin/issues/3351 and https://github.com/gin-gonic/gin/issues/2676
Can we merge this PR ? Panic is redundant. Error can be handled gracefully.
@mayankvaid88 - I hope you are asking can we merge the PR? :)
@mayankvaid88 - I hope you are asking can we merge the PR? :)
Yeah. My bad :)
Hello! Thanks to all for paying attention to this PR. Seems like our maintainers just forgot about this issue in many others.
@appleboy, @thinkerou could you merge this into the main branch, please? If not, it would be nice to provide some feedback to us.
UPD: Fixed unit tests and merged upstream branch into forked.
@appleboy @thinkerou approve the merge request please.
@appleboy please review the pull request, thanks!
@appleboy please review the pull request, thanks!
People, do we really need this approval from @appleboy? Isn't there other contributors that could approve this for us? This is too important and there is several related issues and we are blocked because we are still waiting for a person that is not responding for over 4 years now. Couldn't this review be assigned to somebody else?
For example @danmux or @vkd or @daheige
For example @danmux or @vkd or @daheige
It has to be one of the maintainers before it can be merged
Thanks all guys. We will release v1.9 version asap.