🐛 browser-logs: fields of custom Error objects passed in log context no longer included (since 4.41.0)

[niekert]

Describe the bug
Since version 4.41.0 of @datadog/browser-logs any custom errors included in the log context field are serialized as [Error] instead of the fields being included in the error. I'm not sure if this was intentional, but it altered behavior quite significantly for our logging setup.

To Reproduce
Example code:

class CustomError extends Error {
  constructor(message, opts) {
    super(message);
    this.opts = opts;
  }
}

// initialize logger

datadogLogs.logger.error("just a log", {
  anotherError: new CustomError("something went wrong", {
    please: "showthisInDatadog "
  })
});

We are using this pattern in some places where we aggregate errors, or provide the original error cause as a custom field on the log context (where we do not wrap errors with cause)

Expected behavior

Would expect the behavior to be similar to that of v4.40.0

V4.40.0

V4.41.0

[yannickadam]

Hi @niekert !

Thanks for reporting this issue. We have reverted the behavior of serializing an instanceof Error in 4.42.0. Let us know if everything works as expected.

However, it is our intention to enhance the serialization of certain object types - notably errors - in our next major release.
Currently:

=> JSON.stringify( new Error('Error') )
=> '{}'

This hides the fact that the object was actually an error.

Could you give us more insights about your use-cases, and how you would expect errors to be presented?
Also - have you tried the new Error parameter of the logger APIs, introduced in 4.36.0?
logger.[level](message: string, messageContext?: object, error?: Error)

[niekert]

Hi! Thank you for reverting the change :)

Our main usecase for this is that we have some middleware that wraps errors from an API in a custom Error object (ApiError) which includes some fields like requestId (from headers), url, statusCode. We include the error object in the log context to use fields like requestId. We also use facets, on the @error.url for example for grouping API errors by URL.

Indeed we are using the new Error parameter and it gives us stack traces, which is very nice, but afaik it does not parse the custom fields on error object or does not display those

We also tried to experiment with wrapping errors with cause property in places where we wrap errors and add more contextual data. This works but also seemed to cause custom fields on the error (not the original error) to no longer be displayed. Perhaps we are not using this as intended but wanted to bring this up for context. Thank you!