bithavoc / express-winston

express.js middleware for winstonjs
https://www.npmjs.com/package/express-winston
MIT License
798 stars 186 forks source link

Log on request instead of on response #118

Open oleiba opened 8 years ago

oleiba commented 8 years ago

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.

rosston commented 8 years ago

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?

Ijmir commented 7 years ago

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

thaiat commented 7 years ago

would also be interested in this scenario...

oleiba commented 7 years ago

@Ijmir explained it perfectly.

rosston commented 7 years ago

@Ijmir's explanation makes sense.

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

graham-sportsmgmt commented 7 years ago

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?

rosston commented 7 years ago

@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.

rotimi-best commented 4 years ago

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