Closed peppemanzi closed 1 year ago
So, we add the serializer for the error field in addition to the already existend serialization of error. Correct?
So, we add the serializer for the error field in addition to the already existend serialization of error. Correct? Yes, I think it could be a good solution.
If value provided to error
is an instance of js Error
, we should serialize it as it is done for the err
field, otherwise we should use default serialization. In this way, we don't force modification to existing code when error
field was used to log strings or custom objects/arrays, while we would fix the case when {}
was logged instead of a meaningful serialization of an Error
instance.
Description of the issue
Logging guidelines for Mia-Platform PaaS environment requires errors to be logged using
error
key. Since the default configuration for error serialization is used for pino.js, errors logged usingerror
key are stringified by lc39's logger as an empty object ({}
). Currently, in order to have a correctly logged error,err
key must be used, as described in pino.js docs, however this implies that errors are not indexed by the logging system.A snippet of code for replicating the issue or showing the proposal usage if applicable
main.js:
example.js:
The expected result
Guidelines and logs indexing must be adapted to handle
err
key and/or values havingerror
key should be serialized if they are instances of JavaScriptError
class