Golang : ExecuteTemplate results in errror: `write tcp 127.0.0.1:8080->127.0.0.1:35212: write: broken pipe` with multiple requests

Question

I have something like this:

t, err1 := template.ParseFiles("exampleFile.tmpl")
if err1 != nil {
    panic(err1)
}
err2 := t.ExecuteTemplate(w, "example", someStruct)
if err2 != nil {
    panic(err2)
}

With simple requests, there are no problems.

But if I send two requests very close to each other, about 40% of the time from simple page refreshes from Chrome and a few ajax requests, it results in various different errors (err2):

write tcp 127.0.0.1:8080->127.0.0.1:35212: write: broken pipe
write: connection reset by peer
use of closed network connection
http: panic serving 127.0.0.1:35814: runtime error: slice bounds out of range goroutine 340 (...)

Others seem to have had similar issues, but with no clear resolution.

Another post seems to suggest just to expect this, and retry failed requests:

https://stackoverflow.com/a/31409281/1923095

What's the best Golang way to handle this?

If you can post at least all the code that leads to this path would help. There is a change the connection is not closed. Can you start a playground that we can take a look at. https://play.golang.org/ — tuck, Oct 11 '16 at 17:59
That last post most definitely does not suggest that this is expected (it's really unrelated to your question at all). First run your code with the race detector. You should never see a panic, especially a `slice bounds out of range` error. (please don't handle simple errors with a panic either) — JimB, Oct 11 '16 at 18:16
Isn't that a normal behavior ? If, while the server sends data back to the client, the connection closes, it's normal to stop the process of rendering isn't it ? (And I agree with the above comment, don't use panic for such simple errors) — Depado, Oct 12 '16 at 09:53
@Depado: yes, if the client disconnects during the request, then write errors can be expected, but this is a short lived request over localhost, and there's no indication in the question that the client should be dropping connections. Plus a panic is _never_ expected, and is an indication that there is a programming error involved. — JimB, Oct 12 '16 at 15:57
Using factorlog in this particular project. Bad idea to pretend to use panic. I'm really thinking this was proper behavior and these "errors" (except the last one) are caused by "incorrect" ajax requests. — Zamicol, Oct 12 '16 at 15:58

Golang : ExecuteTemplate results in errror: `write tcp 127.0.0.1:8080->127.0.0.1:35212: write: broken pipe` with multiple requests

0 Answers0