Ability to control exception depth to avoid CPU spikes

[scarlac]

Do you want to request a feature or report a bug?

Feature.

What is the current behavior?

Raven client for NodeJS currently sets MAX_SERIALIZE_EXCEPTION_DEPTH = 3. For large exceptions from external APIs the exception objects may contain a large amount of data and nested keys, causing Sentry to spike NodeJS process, blocking all other actions.

What is the expected behavior?

captureException should allow control over how deep serializeException goes by default. Raven already has a kwargs parameter in which this could reasonably be passed down to serializeException, who's 2nd parameter is the maximum depth.

[lxcid]

Wow, I actually run into this issue, after crazy tracing…

sequelize/sequelize#9652 (comment)

raven-node have been having CPU/Memory spike when capturing exception from time to time in previous release but doesn't seems to be fully resolved.

I face this issue in one incident when axios throw exception on 5xx error which got captured and it crash my server when it crosses 2GB of memory usage.

I would love to be able to control the depth though. I'm using 2.6.2

[lxcid]

I think this might give a hint?

https://github.com/axios/axios/blob/98080381fa78dcffa91a15e6d25617583d13e533/lib/core/settle.js#L18-L23

[scarlac]

Our issue was also that axios dumps everything relating to request and response. This turns out to be a massive amount of fields. Without a proper limit, raven spins out of control, causing server slow down which made the issue worse.

[adriaanmeuris]

can confirm we're seeing this behaviour as described by @scarlac on Axios calls that fail with a 500 error.

I think this can be improved by using the toJSON implementation as described in axios/axios#1625.

Checking for a toJSON property would also improve error logging when logging specific objects like ObjectId's from MongoDB, which currently are displayed like this:

[kamilogorek]

sentry-javascript/packages/utils/src/object.ts

Lines 206 to 210 in 3c10d9c

	// If value implements `toJSON` method, call it and return early
	// tslint:disable:no-unsafe-any
	if (value !== null && value !== undefined && typeof value.toJSON === 'function') {
	return value.toJSON();
	}

Checking for a toJSON property would also improve error logging when logging specific objects like ObjectId's from MongoDB, which currently are displayed like this:

@adriaanmeuris It's coming :)

[adriaanmeuris]

@kamilogorek any idea in which version this would become available?

[kamilogorek]

Closing the issue, as it seems like the original issue has been resolved.
Please do not hesitate to ping me if it is still relevant, and I will happily reopen and work on it.
Cheers!