[$250] [Sentry: APP-6Z4] HybridApp iOS TypeError: this.fetchReport() undefined in ReportController.js

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-6Z4

Impact (snapshot at filing)

• Users (total since first seen): 1,029
• Events: 1,303
• Users (last 14d): 313
• First seen: 2026-03-04
• Last seen: now (ongoing)
• Platform: iOS, hybrid_app
• App version(s): seen on 9.3.25 through 9.3.78
• Mechanism: nsexception, fatal (unhandled JS exception bridged to native)

Stack trace (top frames, first-party only)

app/Controllers/ReportController.js:1770   this.fetchReport().then(...)
  -> -[YAPL performBecomeActiveStateCallback]   (app resume / foreground)
  -> -[YAPLJS callFunction:args:]
  -> -[YAPL logException:]

Suspected cause

this.fetchReport() is invoked from a lifecycle callback when the app becomes active, but this is undefined or the controller instance is not bound — so .then is called on undefined. Likely a lost this context in the become-active handler (missing .bind(this) / arrow function) or a race where the controller is torn down before the callback runs.

Reproduction

Unknown deterministically — Sentry shows it firing on app resume (performBecomeActiveStateCallback) across many iOS versions and app releases. See linked Sentry events for session context.

Related

• Sibling Sentry IDs (if any): none identified
• Prior GH issues: migrated from Expensify/Expensify#605575

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022057737583305255963
• Upwork Job ID: 2057737583305255963
• Last Price Increase: 2026-05-22

Issue Owner

Current Issue Owner: @gijoe0295

Issue Owner

Current Issue Owner: @gijoe0295

[MelvinBot]

Proposal

What is the root cause of that problem?

The crash occurs in OldDot (YAPL) code, not in the NewDot App repo. The stack trace shows:

ReportController.js:1770   this.fetchReport().then(...)
  -> -[YAPL performBecomeActiveStateCallback]

ReportController.js and fetchReport() are part of the YAPL JavaScript bundle that lives in the Mobile-Expensify submodule (Mobile-Expensify/app/), not in this repository. The YAPL native layer (-[YAPL performBecomeActiveStateCallback]) fires a callback into YAPL JS when the iOS app returns to the foreground — but at that point the ReportController instance's this context is undefined.

The most likely mechanism: in HybridApp mode, when the user transitions to NewDot, OldDot's JS context or controller instances get torn down — but the native iOS becomeActive observer registered by YAPL is not unregistered. When the app later resumes from background, the native observer fires into a deallocated or unbound JS controller, causing this.fetchReport() to throw because this is undefined.

Supporting evidence:

• The crash is exclusive to iOS and hybrid_app platform — it does not occur on standalone NewDot or Android
• It fires on app resume (performBecomeActiveStateCallback), not during normal navigation
• It has persisted across many app versions (9.3.25 through 9.3.78), suggesting a structural lifecycle issue rather than a one-time regression
• The HybridApp module's iOS stub in this repo is a no-op — the real native implementation (including becomeActive handling) lives in Mobile-Expensify

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

Since the crash is in the Mobile-Expensify (OldDot/YAPL) codebase, the fix must be made there:

1. In Mobile-Expensify/app/ReportController.js (~line 1770): Add a guard before calling this.fetchReport() — e.g., if (!this) return; or check controller validity before invoking the method
2. In the YAPL native iOS layer (the class that registers performBecomeActiveStateCallback): Ensure the native becomeActive observer is removed when the HybridApp transitions the user to NewDot, so stale callbacks don't fire into a torn-down JS context
3. Alternatively, bind the callback with an arrow function or .bind(this) when registering it, so the this reference is captured at registration time rather than relying on the instance being alive at invocation time

Option 2 (unregistering the observer on transition) is the most robust fix, as it addresses the root cause rather than masking it with a null guard.

What alternative solutions did you explore? (Optional)

A null guard on this (option 1) is simpler but only masks the symptom — the native observer would still fire unnecessarily after the OldDot context is torn down, which could cause other subtle issues. The proper fix is to clean up the native lifecycle observer when it's no longer needed.

---

Related issues

• Expensify/App#89090 — iOS crash on soft-killing the app (potentially related lifecycle issue)
• Migrated from Expensify/Expensify#605575

---

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

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

When the iOS HybridApp resumes from background, -[YAPL performBecomeActiveStateCallback] fires and invokes a JS callback that calls this.fetchReport().then(...) inside ReportController.js around line 1770. At that point this is either undefined (strict-mode class method passed as a plain callback without binding) or the controller instance has already been torn down, so this.fetchReport is undefined and calling .then on undefined throws a fatal TypeError bridged to native as an nsexception.

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

Two fixes are needed: bind the method correctly and guard against a destroyed instance.

1. Bind the become-active handler (or convert to arrow function):

- this.onBecomeActive = function() {
-   this.fetchReport().then(...);
- };
+ this.onBecomeActive = () => {
+   if (!this.fetchReport) return;
+   this.fetchReport().then(...);
+ };

Using an arrow function captures this lexically so it's never lost when the callback is handed off to the native bridge.

2. Add a null-guard before calling .then:

- this.fetchReport().then(...)
+ const reportPromise = this.fetchReport?.();
+ if (reportPromise) {
+   reportPromise.then(...);
+ }

This prevents the fatal crash even if the controller is partially torn down before the resume callback fires (e.g., navigation away mid-session).

3. Unregister the become-active listener on controller teardown:

Ensure the listener is removed in whatever destroy/unmount lifecycle the controller exposes, so a stale callback can never fire after this is gone.

What alternative solutions did you explore?

I considered wrapping the entire callback in a try/catch to swallow the error, but that only hides the symptom. The correct fix is eliminating the lost-this context at the source and cleaning up the listener on teardown.

[KJ21-ENG]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @thesahindia (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022057737583305255963