extremely long auto transactions for react-navigation

[brandonpearcy]

I saw sent here after a few rounds of conversation with Sentry customer support.

OS:

• Windows
• MacOS
• Linux

Platform:

• iOS
• Android

SDK:

• @sentry/react-native (>= 1.0.0)
• react-native-sentry (<= 0.43.2)

SDK version: 5.22.0

react-native version: 0.72.7

Are you using Expo?

• Yes
• No

Are you using sentry.io or on-premise?

• sentry.io (SaaS)
• on-premise

If you are using sentry.io, please post a link to your issue so we can take a look:

Here are some sample transactions that are extremely long:

https://heylo.sentry.io/performance/trace/1e7f705bab9749adb96338cb45f29323/?fov=0%2C73193135.7121582&node=txn-f037f7af2d2a42a59d9a4c3f8cc77bf2&pageEnd=2024-05-22T20%3A38%3A53.000&pageStart=2024-05-22T20%3A36%3A10.000&timestamp=1716410316

https://heylo.sentry.io/performance/trace/8f8e52c16a6545a3a2f6f571584c6ee4/?fov=0%2C238348109.14990234&node=txn-e1756085d2824a5c8b988214b492ee24&statsPeriod=24h&timestamp=1716394519

Configuration:

    Sentry.init({
      appHangTimeoutInterval: 5, // seconds
      dsn: heyloConfig.SENTRY_DSN,
      enableAutoPerformanceTracing: true,
      enableAutoSessionTracking: true,
      environment: Config.BUILD_VARIANT_STRING,
      integrations: [
        new Sentry.ReactNativeTracing({
          enableAppStartTracking: true,
          enableNativeFramesTracking: true,
          enableStallTracking: true,
          enableUserInteractionTracing: true,
          routingInstrumentation,
          // Uncomment to sample subsequent navigations to a route already seen
          // ignoreEmptyBackNavigationTransactions: true,
        }),
      ],
      // Set tracesSampleRate to 1.0 to capture 100% of transactions for performance monitoring.
      // We recommend adjusting this value in production.
      tracesSampleRate: 0.01,
    })

---

I have the following issue:

We are seeing a lot of extremely long automatic react-navigation transactions. It looks like the app start time is used even if it was hours or days ago. E.g. the app starts 1 day ago, so we'll have a app.start.warm event 1 day ago, 1 day worth of "missing instrumentation", and then a navigation.processing event. These are causing our p50, p75, p95 and p99 metrics to be essentially useless for optimization work.

Ideally, app start events would only be included in the transaction of the very next navigation in the app's lifecycle. Right now, it seems like the app start events are being included in all navigation transactions.

I found some old Github issues describing a similar sounding bug. Perhaps it has re-emerged? #3044

[krystofwoldrich]

Hi @brandonpearcy,
thank you for the message, you are definitely at the right place. Due to an ongoing conference this week, we might be slower to response.

Wi will investigate this and update you here in the issue.

I've briefly checked the linked transaction and it looks the same as #3044.