Clears error collections on transaction end after processing. #712
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Proposed Release Notes
Fixed issue where capturing axios request errors could result in a memory leak.
The agent now clears error references on transaction end, which are not used for later processing. Errors returned from 'axios' requests contain a reference to the request object which deeper down has a handle to a promise in
handleRequestError
. The TraceSegment associated with that promise has a handle to the transaction, which through the error capture ultimately kept the promise in memory and prevented it from being destroyed to free-up the TraceSegment from the segment map. This change also has the benefit of freeing up some memory early for transactions held onto for transaction traces.Added active transaction check to
wrappedResEnd
to prevent unecessary work for ended transactions in the case of multipleResponse.prototype.end()
invocations.Links
Details
Ideally, I'd like to avoid holding onto user errors passed-in at all. Unfortunately, this requires touching several place and doesn't play well with our duplicate error detection. The duplicate detection uses the object itself as a key to avoid situations such as an end user calling
noticeError(error)
on the same instance twice on accident.It may be worth considering if that safety mechanism isn't something we want/need to keep around. I'm not sure if any other agents do similar but I don't remember anything like that from my previous team.
I'm going to submit a separate issue to dig into this further.
While this change has the benefit of also just freeing up some memory sooner... there is some risk in clearing things off the transaction as we might in the future attempt to do something with this information later after transaction end. Unlikely at this point but calling out. More likely would be haphazardly adding something that is used by transaction traces in here to clear out as well.