Closed jonathansamines closed 2 years ago
How is the pino-std-serializers
module implicated in this?
@jsumners Framework-specific libraries that are build on top of pino would usually pass a reference to the res
object when logging the response details as part of their access logs implementation:
pino-std-serializers will then take the response object and serialize it by copying the res.statusCode
reference from the response object:
This is the reason why I think pino-std-serializers is the best place to update how the res.statusCode
is included in the final logs. The current implementation is:
I'd suggest moving to:
_res.statusCode = res.headersSent ? res.statusCode : null
Would you like to send a Pull Request to address this issue? Remember to add unit tests.
@mcollina Sure thing, I just created #103
access-logs-aborted-requests
See reproduction repository
Problem
When the client aborts a request before the server is able to respond, then the response status code is always captured as
200
.How to reproduce?
A reproduction code is included for both express and hapi.js. The
server.js
andhapi-server.js
scripts create a simple server with two endpoints:/immediate
- responds back immediately/delayed
- responds back after a delay of 100msExpress server
Hapi server
Test cases
The
client.js
script performs two requests to the server:/immediate
/delayed
. This request is aborted after 10ms, long before the server responds backResults
pino-http
Completed request
Log is correct
Aborted request
Log is not created. There is an open pull request to fix it.
Hapi server
hapi-pino
Completed request
Log is correct
Aborted request
Log is incorrect. Status code is included as
200
in bothmsg
andres.statusCode
, even when the request was aborted.Suggested fix
Other existing access logs libraries (e.g morgan), just capture the response status code when headers have been flushed. I'd suggest we do the same