Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Chiusa Adatta ai principianti
  • Qualcosa non va?
#6,821 2 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@antonis ci sta già lavorando.

Dal 2/10/2026.

  • #6823 di @antonis — aperta

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
78/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
android, react-native, typescript
Ambito
mobile

Direzione di ricerca

Leggi android/src/main/java/io/sentry/react/RNSentryModuleImpl.java e confronta initNativeReactNavigationNewFrameTracking con l’implementazione iOS in ios/RNSentry.mm. Verifica come vengono gestiti i metodi che restituiscono Promises in src/js/turbomodule/wrapTurboModule.ts; l’issue suggerisce inoltre di verificare anche gli altri metodi che ricevono Promises in RNSentryModuleImpl. Il lavoro è completo quando questa chiamata non lascia più bloccato un frame del tracker e il comportamento Android corrisponde alla risoluzione prevista della Promise.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Bug React-Native
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)
Lingua principale
TypeScript
Stelle
1.8k
Fork
369
Merge medio
20h 46m
PR unite (30g)
106

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di getsentry/sentry-react-native

Tutte le issue di getsentry/sentry-react-native

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.