Skip to content

Default depth for ExtraErrorData not applied #4186

@rchl

Description

@rchl

Package + Version

  • @sentry/browser
  • @sentry/node
  • raven-js
  • raven-node (raven for node)
  • other:

Version:

6.14.1

Description

I have just finished investigating some nasty issue where triggering an error on the server side resulted in 100% CPU usage and eventually getting OOM.

The infinite loop triggered from the ExtraErrorData integration, when it tried to normalize an axios error using normalize function from

return JSON.parse(JSON.stringify(input, (key: string, value: any) => walk(key, value, depth)));

Turns out the issue only manifests itself when also having dd-trace enabled in the service but that's not necessarily the root issue. The issue for me was that I have passed an empty object to the ExtraErrorData constructor:

public constructor(private readonly _options: ExtraErrorDataOptions = { depth: 3 }) {}

That resulted in depth being undefined rather than defaulting to 3 and this trigged this infinite loop.

Now, I'm not sure what's the main issue here:

  • the fact that depth doesn't default to 3 when empty object is provided? This integration only accepts the depth option but if it would support more options, would it make sense to use default value for options that are not provided? I think it would, so it probably also makes sense to do that when only one option is supported.
  • why does it go into an infinite loop when dd-trace is enabled but not otherwise? Shouldn't it break the cycle in any case? I haven't investigated what exactly makes it go into an infinite loop but must be something that dd-trace does with the Request/Response objects that the axios error contains.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions