Look into avoiding storage of actual errors upon noticing

[michaelgoin]

Is your feature request related to a problem? Please describe.

Frameworks and users may store all sorts of information we don't use on errors that we automatically notice or capture via the noticeError API. For example: 'axios' stores the request object on the errors when receiving a 500 status code.

Storing the actual error means we hold this extra info in memory until the transaction has finished, whether or not it may clear up sooner. While we've reduced some surface risk there but clearing out on transaction end, it would still be nice not to have any future concerns here. If we could just grab what we need we can then free up the object.

There's just one larger hurdle: our duplicate error detection uses the object as a key to try to help prevent end-users from calling noticeError() on the same error twice (or maybe even ourselves from seeing something twice via instrumentation). While a nice safety feature, this requires holding the original objects in memory.

We should determine if this feature exists for any other agents or if there is a partial safety measure we can put in place, that is not expensive. Removing this feature should probably be a major version bump, if we go that route.

See:

• Clears error collections on transaction end after processing. #712
• Agent introduces memory leak when axios errors noticed #710

[michaelgoin]

https://issues.newrelic.com/browse/NR-35655