[Due for payment 2026-03-31] [Due for payment 2026-03-30] Expense - App crashed when tap on "Try it out" button

[nlemma]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.41-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176924/test-cases/41237576
Email or phone of affected tester (no customers): rybkina+031826not@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: iOS
App Component: Other

Action Performed:

1. Signup with a new Gmail account
2. Select Track and budget expenses on onboarding > finish onboarding
3. Tap Create expense
4. Tap on "Try it out" button in the tool tip

Expected Result:

Manager McTest should be appeared.

Actual Result:

App crash when tap on "Try it out" button. Same issue when tap on "No thanks" as well.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Bug7107841_1773963845571.ScreenRecording_03-19-2026_18-31-31_1.mp4

Bug7107841_1773963845574!Expensify-2026-03-19-183156.txt

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

[melvin-bot]

Triggered auto assignment to @srikarparsi (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After completing onboarding (Track and budget expenses), tapping "Create expense" then tapping either the "Try it out" or "No thanks" button on the scan test tooltip causes an iOS app crash (EXC_BAD_ACCESS / SIGSEGV at address 0xa). Reproducible in staging (9.3.41-0) but not production.

What is the root cause of that problem?

PR #85409 ("[NO QA] Track when we show the scan test tooltip", merged March 18) added GoogleTagManager.publishEvent() calls to both the onConfirm and onDismiss callbacks for the SCAN_TEST_TOOLTIP in IOURequestStartPage.tsx:267-277.

Both button handlers call GoogleTagManager.publishEvent(), which internally calls logEvent(analytics, ...) from @react-native-firebase/analytics in GoogleTagManager/index.native.ts:10. This logEvent dispatches to the native TurboModule queue (com.meta.react.turbomodulemanager.queue), where Hermes crashes with a null pointer dereference (address 0xa = nil + 10 byte offset).

The crash affects both buttons because GoogleTagManager.publishEvent() is the only code common to both onConfirm and onDismiss callbacks that was added by PR #85409. The tooltip itself is gated behind the NEWDOT_MANAGER_MCTEST beta (IOURequestStartPage.tsx:265), which explains why it only crashes in staging (beta enabled) and not production.

Additionally, this staging release includes the React Native 0.81.4 → 0.83.1 upgrade (PR #79962), which may have introduced a regression in how Firebase Analytics TurboModule calls are dispatched from Portal-rendered content (the tooltip buttons render inside a @gorhom/portal via BaseGenericTooltip/index.native.tsx).

What changes do you think we should make in order to solve the problem?

Immediate fix (deploy blocker): Revert PR #85409 to remove the GoogleTagManager.publishEvent() calls from the tooltip button handlers. This restores the previous working behavior where the tooltip buttons function without triggering Firebase Analytics native module calls.

Alternative targeted fix: Wrap the logEvent call in GoogleTagManager/index.native.ts with a try/catch to prevent unhandled native crashes:

function publishEvent(event: GoogleTagManagerEvent, accountID: number) {
    try {
        logEvent(analytics, event as string, {user_id: accountID});
    } catch (error) {
        Log.warn('[GTM] Failed to publish event', false, {event, error});
    }
    Log.info('[GTM] event published', false, {event, user_id: accountID});
}

What alternative solutions did you explore? (Optional)

• Investigated whether the RN 0.83 upgrade alone is the root cause — while the upgrade may contribute (17 deploy blockers in this release), PR [NO QA] Track when we show the scan test tooltip #85409 is the direct trigger since it added the crashing publishEvent calls
• Considered whether the Portal rendering context is the issue — the buttons render inside @gorhom/portal, which may affect TurboModule dispatch, but the simplest fix is to remove/protect the crashing call rather than fix the Portal interaction

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot to refine this analysis, or explain why you are rejecting Melvin's proposal.