Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Android: turbo_module.* crash tags permanently pinned to RNSentry.initNativeReactNavigationNewFrameTracking (promise never settles)

Open Beginner friendly
  • Is something wrong?
#6,821 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
android, react-native, typescript
Domain
mobile

Research direction

Read android/src/main/java/io/sentry/react/RNSentryModuleImpl.java and compare initNativeReactNavigationNewFrameTracking with the iOS implementation in ios/RNSentry.mm. Check how promise-returning methods are handled in src/js/turbomodule/wrapTurboModule.ts; the issue also suggests auditing other Promise-taking methods in RNSentryModuleImpl. Done when this call no longer leaves a tracker frame stuck and the Android behavior matches the intended promise settlement.

Written by the indexing model from the issue text.

Description

Bug React-Native Waiting for: Product Owner
Summary

On Android, the crash-time TurboModule attribution added in #6227 is permanently pinned to a single startup call. Every native crash report from an Android app carries:

turbo_module.name:   RNSentry
turbo_module.method: initNativeReactNavigationNewFrameTracking

regardless of what was actually executing. The tags are not stale-by-a-moment; they are stuck for the entire process lifetime, so the feature reports a wrong answer rather than no answer. iOS is unaffected.

Cause

Three facts compose:

  1. wrapTurboModule pops a tracker frame for a promise-returning method only when that promise settles (src/js/turbomodule/wrapTurboModule.ts — the isThenable(result) branch pops in both then handlers).

  2. The Android implementation never settles the promise:

    // android/src/main/java/io/sentry/react/RNSentryModuleImpl.java
public void initNativeReactNavigationNewFrameTracking(Promise promise) {
  this.initFragmentInitialFrameTracking();
}

    promise is accepted and dropped — no resolve, no reject, no path that settles it later. iOS does the equivalent work and then calls resolve(nil) (ios/RNSentry.mm).

  3. RNSENTRY_SKIP in turboModuleContextIntegration does not include this method, so it is wrapped like any other.

The frame pushed at startup therefore never pops. popTurboModuleCall walks the stack and re-syncs the scope onto "the newest remaining frame on the same scope" after every subsequent pop — which, once the app is idle, is always the leaked startup frame. The native scope is left holding it, and sentry-java serialises it into every crash report.

Two smaller consequences of the same leak: the tracker stack never drains to empty (so clearScope's empty-string sentinel path is unreachable on Android), and the aggregate record for that call is never emitted.

Steps to reproduce
  1. Expo app on Android with enableTimeToInitialDisplay on (expoRouterIntegration or reactNavigationIntegration).
  2. Let the app finish starting, navigate anywhere, idle.
  3. Trigger any native crash — e.g. Sentry.nativeCrash() — or read getTurboModuleCallStack().
  4. The event's tags report RNSentry.initNativeReactNavigationNewFrameTracking as the in-flight call; the stack still holds that frame.
Suggested fix

Settle the promise in the Android implementation, mirroring iOS:

public void initNativeReactNavigationNewFrameTracking(Promise promise) {
  this.initFragmentInitialFrameTracking();
  promise.resolve(null);
}

Adding the method to RNSENTRY_SKIP would hide the symptom but leave the dangling promise, so the native-side fix seems the right one. It may be worth auditing the other Promise-taking methods in RNSentryModuleImpl for the same shape.

Versions
  • @sentry/react-native: reproduced on 8.27.0; the Android code is unchanged on 8.29.0 (current latest)
  • Platform: Android only (iOS resolves correctly)
Dominant language
TypeScript
Stars
1.8k
Forks
369
Avg merge
20h 55m
Merged PRs (30d)
105

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from getsentry/sentry-react-native

All issues in getsentry/sentry-react-native

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.