Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Look into avoiding storage of actual errors upon noticing #2505

Open
kmudduluru opened this issue Aug 20, 2024 · 1 comment
Open

Look into avoiding storage of actual errors upon noticing #2505

kmudduluru opened this issue Aug 20, 2024 · 1 comment
Labels
points: 8 risk: high This change impacts critical areas or has other traits that warrant very careful consideration.

Comments

@kmudduluru
Copy link
Contributor

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

 

 

#713

Additional context

Look into this issue for additional context

@workato-integration
Copy link

@kmudduluru kmudduluru added risk: high This change impacts critical areas or has other traits that warrant very careful consideration. and removed needs-triage labels Aug 20, 2024
@newrelic-node-agent-team newrelic-node-agent-team moved this to Triage Needed: Unprioritized Features in Node.js Engineering Board Aug 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
points: 8 risk: high This change impacts critical areas or has other traits that warrant very careful consideration.
Projects
Status: Triage Needed: Unprioritized Features
Development

No branches or pull requests

1 participant