fix(tracing): Unsubscribe spanEnd listeners after they fire to prevent accumulation#5840
Open
fix(tracing): Unsubscribe spanEnd listeners after they fire to prevent accumulation#5840
Conversation
…t accumulation
Each `client.on('spanEnd')` registered in `onSpanEndUtils` is a one-shot
listener — it cares about exactly one specific span ending. Previously the
unsubscribe function returned by `client.on()` was discarded, leaving all
listeners in the client's hook set indefinitely.
Over the lifetime of an app with frequent navigation, this caused listeners
to accumulate: each navigation span left 3–4 zombie listeners that fired on
every subsequent spanEnd event and returned early via an identity check. On
low-end devices this contributes measurable overhead, especially when many
child spans (HTTP requests) end during active navigation transactions.
The fix captures and calls the unsubscribe function as the first action once
the target span is identified, making every listener self-removing.
Also adds a dedicated test file for `onSpanEndUtils` covering unsubscribe
behaviour for all five functions, including a regression test that verifies
listener count does not grow across multiple spans.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Contributor
Semver Impact of This PR⚪ None (no version bump detected) 📋 Changelog PreviewThis is how your changes will appear in the changelog.
🤖 This preview updates automatically when you update the PR. |
Contributor
antonis
commented
Mar 18, 2026
Contributor
Author
There was a problem hiding this comment.
Since this is more of an internal implementation fix with no user-facing behavior change I'll skip changelog. I would suggest to add a changelog entry when all the improvements of #5665 are delivered. Happy to add it if you feel it is needed.
Contributor
Author
|
@sentry review |
Contributor
Author
|
@cursor review |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
The NativeFrames and StallTracking integrations performed their full work (native bridge calls, 50ms polling loop) regardless of whether the span would be sampled, unlike the Profiling integration which already checks spanIsSampled() correctly. With tracesSampleRate: 0.2, this meant 80% of navigation spans triggered unnecessary fetchNativeFrames() bridge calls and stall tracking loop activations. On low-end devices these operations are significantly more expensive and contribute to the performance overhead reported in #5665. The fix adds a spanIsSampled() guard at the entry of fetchStartFramesForSpan in NativeFrames and _onSpanStart in StallTracking. Since end-frame fetching already bails when no start frames are found, the single guard in fetchStartFramesForSpan covers both start and end for NativeFrames. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…pled spans" This reverts commit c81ce4d.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
📢 Type of change
📜 Description
Each
client.on('spanEnd')registered inonSpanEndUtilsis a one-shot listener — it only cares about one specific span ending. Previously the unsubscribe function returned byclient.on()was discarded, leaving listeners in the client's hook set indefinitely.The fix captures and calls the unsubscribe function as the first action once the target span is identified, making every listener self-removing. All five functions in the file are updated:
onThisSpanEnd,adjustTransactionDuration,discardEmptyNavigationSpan(shared byignoreEmptyBackNavigationandignoreEmptyRouteChangeTransactions),onlySampleIfChildSpans, andcancelInBackground.💡 Motivation and Context
Over the lifetime of an app with frequent navigation, these listeners accumulated: each navigation span left 3–4 zombie listeners that fired on every subsequent
spanEndevent system-wide and returned early via an identity check. On low-end devices this contributes measurable overhead, especially when many child spans (HTTP requests) end during active navigation transactions.Related issue: #5665
💚 How did you test it?
Added a dedicated test file
test/tracing/onSpanEndUtils.test.tswith 11 tests covering:onThisSpanEndcancelInBackgroundAll existing
reactnavigationtests (93) continue to pass.📝 Checklist
sendDefaultPIIis enabled🔮 Next steps
Part of a broader investigation into
reactNavigationIntegrationperformance on low-end devices (#5665). Other improvements being tracked in that issue.