-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2.4.0 eats Error objects when logging #1178
Comments
This is the original formatter code IIRC https://github.com/eugeny-dementev/winston-console-formatter, modified a bit |
since 2.3.1 is also fine the regression might be caused by this ? bac951c |
I was bitten by this too and can confirm that, in my case, it was caused by #977, which is between 2.3.1 and 2.4.0. (Errors passed in in It appears that running cycle.decycle() removes much information, such as the stack trace, from an error.
edit: upon closer inspection, I'm not sure what is going in the case of #1007, but what is going in my problem case is that I am using a formatter. Thus, when winston runs |
Fixes winstonjs#1178 When we use a formatter and pass an `Error` object in as `meta`, we end up removing the Error's message and stack information when `decycle`ing it. `clone` checks if the passed-in object is an `Error` and does not `decycle` it in that case, but when we use a formatter, this check does not happen because we `clone` the whole `options` object instead of just cloning `options.meta`. Simply removing the `&& !(options.meta instanceof Error)` from this line fixes the problem, by forcing it to `clone` `meta` the first time, when the `instanceof Error` check will catch it and copy `message` and `stack` into a new, non-Error object. So when that's buried in `options.meta`, re-`clone`ing it won't hurt. Reading the code it seems to not have any bad side-effects. In the places that use meta, double-`clone`ing is done anyway for other non-`Error` objects, and the if conditions (`typeof meta !== 'object' && meta != null`) would pass wither way for `Error` objects or non-`Error` objects.
Fixes winstonjs#1178 When we use a formatter and pass an `Error` object in as `meta`, we end up removing the Error's message and stack information when `decycle`ing it. `clone` checks if the passed-in object is an `Error` and does not `decycle` it in that case, but when we use a formatter, this check does not happen because we `clone` the whole `options` object instead of just cloning `options.meta`. Simply removing the `&& !(options.meta instanceof Error)` from this line fixes the problem, by forcing it to `clone` `meta` the first time, when the `instanceof Error` check will catch it and copy `message` and `stack` into a new, non-Error object. So when that's buried in `options.meta`, re-`clone`ing it won't hurt. Reading the code it seems to not have any bad side-effects. In the places that use meta, double-`clone`ing is done anyway for other non-`Error` objects, and the if conditions (`typeof meta !== 'object' && meta != null`) would be false either way for `Error` objects or non-`Error` objects.
Fixes winstonjs#1178 When we use a formatter and pass an `Error` object in as `meta`, we end up removing the Error's message and stack information when `decycle`ing it. `clone` checks if the passed-in object is an `Error` and does not `decycle` it in that case, but when we use a formatter, this check does not happen because we `clone` the whole `options` object instead of just cloning `options.meta`. Simply removing the `&& !(options.meta instanceof Error)` from this line fixes the problem, by forcing it to `clone` `meta` the first time, when the `instanceof Error` check will catch it and copy `message` and `stack` into a new, non-Error object. So when that's buried in `options.meta`, re-`clone`ing it won't hurt. EDIT: this appears to (possibly negatively) affect code further down in the function, where we check if `meta instanceof Error`, so is maye not a good solution.
Fixes winstonjs#1178 When we use a formatter and pass an `Error` object in as `meta`, we end up removing the Error's message and stack information when `decycle`ing it. `clone` checks if the passed-in object is an `Error` and does not `decycle` it in that case, but when we use a formatter, this check does not happen because we `clone` the whole `options` object instead of just cloning `options.meta`. By `clone`ing `meta` alone when it is an Error, the `instanceof Error` check will catch it and copy `message` and `stack` into a new, non-Error object. So when that's buried in `options.meta`, re-`clone`ing it won't hurt.
Fixes winstonjs#1178 When we use a formatter and pass an `Error` object in as `meta`, we end up removing the Error's message and stack information when `decycle`ing it. `clone` checks if the passed-in object is an `Error` and does not `decycle` it in that case, but when we use a formatter, this check does not happen because we `clone` the whole `options` object instead of just cloning `options.meta`. By `clone`ing `meta` alone when it is an Error, the `instanceof Error` check will catch it and copy `message` and `stack` into a new, non-Error object. So when that's buried in `options.meta`, re-`clone`ing it won't hurt.
Add test for "Don't swallow Error message/stack when using formatter", which Fixes winstonjs#1178
I'm using 3.0.0-rc4, and observed that when log error with error object; process.on('unhandledRejection', (reason, p) => {
logger.log.error(reason, 'Unhandled Rejection at Promise', p);
}); It logs
But if I use
|
Duplicate of #1007. @amitguptagwl the |
* Don't swallow Error message/stack when using formatter Fixes #1178 When we use a formatter and pass an `Error` object in as `meta`, we end up removing the Error's message and stack information when `decycle`ing it. `clone` checks if the passed-in object is an `Error` and does not `decycle` it in that case, but when we use a formatter, this check does not happen because we `clone` the whole `options` object instead of just cloning `options.meta`. By `clone`ing `meta` alone when it is an Error, the `instanceof Error` check will catch it and copy `message` and `stack` into a new, non-Error object. So when that's buried in `options.meta`, re-`clone`ing it won't hurt. * Add test Add test for "Don't swallow Error message/stack when using formatter", which Fixes #1178
It seems there is the same problem in v3.3.3. It eats/swallows error.message if error is provided with a introduction string, like this: |
After upgrading from 2.3.0 to 2.4.0, winston stops logging errors when using:
I am using this piece of code for
formatter
on 2.4.0 there is no stack/trace etc. there is no sign of the error object in the arguments.
the result is that the error is not printed to logs correctly.
downgrading to 2.3.0 fixes the problem.
upgrading to 3.0.0-rc1 + using winston.createLogger
makes the app loop forever displaying the first log message which is really weird :|
The text was updated successfully, but these errors were encountered: