express-winston icon indicating copy to clipboard operation
express-winston copied to clipboard

Log on request instead of on response

Open oleiba opened this issue 8 years ago • 8 comments

Hi, It would be great if I'd had the option to configure expressWinston in a way that it would log messages on request instead of on response. This is important for cases such when a server crashes and does not respond with any response (timeout for example). Similar behavior is implemented in morgan when initiatlized with immediate: true.

oleiba avatar Aug 21 '16 10:08 oleiba

Hm, that's a pretty fundamental change to the module as a whole, but I'm interested in your scenario. In the case where the server crashes or times out, isn't that a scenario that the express-winston error logger should already be handling?

rosston avatar Aug 31 '16 01:08 rosston

if server crashed it doesn't reach the errorLogger and the request that caused this is lost

Ijmir avatar Nov 28 '16 15:11 Ijmir

would also be interested in this scenario...

thaiat avatar Nov 29 '16 12:11 thaiat

@Ijmir explained it perfectly.

oleiba avatar Nov 29 '16 12:11 oleiba

@Ijmir's explanation makes sense.

PRs are welcome. I may get to this myself, but it's not my highest priority.

rosston avatar Nov 29 '16 19:11 rosston

Forgive me for commenting when I'm just getting started with this package, but would it be possible to just call express-winston from the uncaughtException event?

https://nodejs.org/docs/latest/api/process.html#process_event_uncaughtexception

Instead of redesigning the whole product just to catch exceptions, can't we just add a stub into the node event handlers and do it that way on demand?

graham-sportsmgmt avatar Jun 28 '17 02:06 graham-sportsmgmt

@graham-sportsmgmt You're right that uncaughtException would handle logging for most server-crash scenarios. I think the problem with that in @oleiba's use case is that there wouldn't be any way to identify which request caused an unhandled exception.

rosston avatar Jul 09 '17 21:07 rosston

My use case is, it makes it easier when I am reading the logs in case of debugging to see when the request came in, then see what other things happened before the response or if the response didn't happen at all.

I think the problem with that in @oleiba's use case is that there wouldn't be any way to identify which request caused an unhandled exception.

Yes exactly

rotimi-best avatar May 05 '20 07:05 rotimi-best