Include additional error properties from nested error causes
As a follow-up to https://github.com/DataDog/browser-sdk/issues/2569, it would be very helpful if each error in the cause chain was logged with all of their additional properties (rather than just the message, source, type and stack)
This would be very helpful for us in cases where we want to include additional debugging information in an error we are throwing in a deep context which is then embedded as a cause and reported to datadog. We have had to work around this by just including it in the error message for now. See: https://github.com/pixiebrix/pixiebrix-extension/pull/9262/files
For reference this was the change to support error causes: https://github.com/DataDog/browser-sdk/pull/2602/files
Thank you for your feedbak and sorry for the delay. We are considering adding support for additional context through a dd_context property, so your usecase could look like this:
const error = new SandboxTimeoutError('Sandbox message timed out')
error.dd_context = {
type: type,
sent: messageMetadata?.timestamp,
payloadSize: messageMetadata?.payloadSize,
pendingMessageCount: pendingMessageMetadataMap.size
}
throw error
How does that sound?
Yes, that would be very helpful!
This was released in v6.4.0 (see PR)
@BenoitZugmeyer sorry for the late response on this - but this actually didn't fit what we were asking for, which was supporting a custom context field on nested causes of the error.
i.e. supporting:
const nestedError = new Error("nested");
nestedError.dd_context = {prop1: "val 1"}
const reportedError = new Error("wrapped", {cause: nestedError})
datadogLogs.logger.error("error message", {}, reportedError);
Right now datadog only checks the top-level error for a dd_context.
Perhaps we could add the dd_context attribute to the flattened list of causes here? https://github.com/DataDog/browser-sdk/blob/main/packages/core/src/domain/error/error.ts#L94-L98
I can't re-open this issue, so I can create a new one to ask the same feature request if necessary.
@fungairino , did you ever find a good solution for this? Did you file a new issue?
We didn't open a follow up issue. We ended up doing some custom processing on the before publish hook to bubble up some additional context from nested errors