Open oleiba opened 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?
if server crashed it doesn't reach the errorLogger and the request that caused this is lost
would also be interested in this scenario...
@Ijmir explained it perfectly.
@Ijmir's explanation makes sense.
PRs are welcome. I may get to this myself, but it's not my highest priority.
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 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.
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
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
.