Twirp server emits 200 status code when it fails to write the response

[Aerendel]

While troubleshooting some errors, I noticed that in rare cases where twirp fails to write out all the response bytes to the response (for example due to some i/o timeout), the response status code is still set to 200. However, the error is caught and sent to error hooks which leads to weird situations where one might see a twirp error logged, yet a success status code. From a client perspective, I haven't been able to test this but I imagine you would get an HTTP 200 with an incomplete / impossible to parse response.

The code in question is here. Line 1357 sets the 200 status, and after on line 1363 write errors are handled but the status code is unchanged.

There might be a good reason for this, but I think this should be served as 5xx status?

Happy to help work on a pull request if this is a valid bug that you think should be fixed, or please let me know if this behavior is by design.

[ojarva]

Headers are written first when sending the response to the client.

If writing the body fails, client will see 200 but incomplete response. On the server side this is detected, and it makes sense to call the error hook. There's no mechanism in the HTTP protocol to change the status after it has already been sent.