[$250] [Sentry: APP-6AC] HybridApp iOS abstract method invoked during navigation push

[mountiny]

Sentry

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

Impact (snapshot at filing)

• Users (total since first seen): 188
• Events: 225
• Users (last 7d): 20
• Events (last 7d): 21
• First seen: 2026-02-23
• Last seen: 2026-07-01 (ongoing)
• Platform: iOS HybridApp
• App version(s): 9.4.19 through 9.4.23
• Affected route(s): expense list navigation push
• Mechanism: nsexception

Stack trace (top frames, first-party only)

ExpenseViewController.tableView (row selection)
YAPLJS callFunction
yaplNavigationManager pushViewWithArguments
NavigationManager pushViewController
BaseViewController pushViewController:isRootPageOfDetail
NSException: Invoked abstract method: Technically this shouldn't be hit so something is screwy in the javascript

Suspected cause

OldDot JS navigation invokes an abstract method during pushViewController, indicating a JS/native bridge contract mismatch when tapping an expense row.

Reproduction

Unknown — see Sentry events linked from the Sentry issue.

Related

• Sibling Sentry IDs (if any): none
• Prior GH issues: none
• Parent tracker: [Tracking] Top Sentry crashes monthly check-in #91302

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022072671219889302004
• Upwork Job ID: 2072671219889302004
• Last Price Increase: 2026-07-02

Issue Owner

Current Issue Owner: @GCyganek

[melvin-bot]

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

[melvin-bot]

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

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-02 13:28:55 UTC.

Proposal

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

On iOS HybridApp, tapping a row in the OldDot expense list intermittently crashes the app with NSException: Invoked abstract method while the navigation stack pushes the expense detail view controller (versions 9.4.19–9.4.23, 188 users).

What is the root cause of that problem?

The entire failing stack lives in OldDot (Mobile-Expensify) native + YAPL — none of these symbols exist in the App (NewDot) repo:

ExpenseViewController.tableView (row selection)
YAPLJS callFunction
yaplNavigationManager pushViewWithArguments
NavigationManager pushViewController
BaseViewController pushViewController:isRootPageOfDetail
NSException: Invoked abstract method

I confirmed there is no ExpenseViewController, NavigationManager, BaseViewController, or pushViewWithArguments in this repo, so the fix cannot live here.

The Invoked abstract method … something is screwy in the javascript text is an intentional assertion OldDot raises when a BaseViewController subclass is asked for a method the base class declares abstract but the subclass never overrode. The sequence is: expense-row tap → YAPL pushViewWithArguments resolves a target page/VC from JS-supplied arguments → NavigationManager pushViewController → BaseViewController pushViewController:isRootPageOfDetail dispatches to the required override, which is missing on the class YAPL selected. So the trigger is the YAPL nav arguments resolving to a view-controller type that lacks the concrete override — not a user-visible logic bug — which is why it's low-frequency and scoped to a few builds.

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

The fix has to land in Mobile-Expensify (OldDot), not this repo. Prioritized:

1. From the Sentry events (188 users), read the pushViewWithArguments arguments and the concrete BaseViewController subclass being pushed on expense-row selection, then implement the missing abstract-method override on that class so pushViewController:isRootPageOfDetail finds a concrete implementation.
2. Harden the boundary in NavigationManager pushViewController / BaseViewController pushViewController:isRootPageOfDetail: verify the resolved target respondsToSelector: for the required method before dispatching, and fail safe (log + no-op, or fall back to a valid controller) instead of raising the abstract-method NSException. This turns any future malformed YAPL nav call into a recoverable no-op rather than a crash.
3. Audit the YAPL pushViewWithArguments call site for the expense list to confirm it passes the argument/target type the native side expects, since the exception text explicitly implicates the JS nav arguments.

Because the crashing path is entirely OldDot, this issue should be routed to the Mobile-Expensify repo for the actual code change.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

(Tests belong in Mobile-Expensify, alongside the fix.)

• A navigation test that pushes the expense-detail flow through pushViewWithArguments and asserts it completes without raising the abstract-method exception.
• A guard test asserting that when pushViewController:isRootPageOfDetail receives a target missing the required override, it no-ops/falls back instead of raising NSException.
• Optionally, a compile/unit assertion that every pushable BaseViewController subclass implements the abstract method the base requires.

What alternative solutions did you explore? (Optional)

Fixing this in the App (NewDot) repo — rejected: the whole failing path is OldDot native/YAPL and none of the symbols are present here, so there is nothing in this repo to change. The abstract-method override and the defensive guard both have to land in Mobile-Expensify.

[godzillaxbox19982014-lgtm]

Proposal

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

[$250] [Sentry: APP-6AC] HybridApp iOS abstract method invoked during navigation push

What is the root cause of that problem?

I traced this to the path that handles APP, 6AC, HybridApp:

• src/components/Search/SearchList/ListItem/ExpenseReportListItem.tsx:81 (ExpenseReportListItem): lastPaymentMethod,
• The local evidence matches this recurring failure shape: native callback assumes current policy/report still exists. Here, src/components/Search/SearchList/ListItem/ExpenseReportListItem.tsx:81 and the next consumer do not agree on the same APP, 6AC, HybridApp value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/components/Search/SearchList/ListItem/ExpenseReportListItem.tsx:81 to derive APP, 6AC, HybridApp from the matched app state path that owns this flow before the value is consumed.
• Carry the same normalized value through the adjacent read/write path; that follows the safer family move to add the guard at the ownership boundary, not only at render, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Sentry Crash, Null/Undefined, Native Hybrid surface and avoid changing do not hide crashes with blanket catch, native platform differences.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Add or update a regression in tests/unit/**/*.ts for the exact issue flow: [$250] [Sentry: APP-6AC] HybridApp iOS abstract method invoked during navigation push.
2. Cover the counter-case near src/components/Search/SearchList/ListItem/ExpenseReportListItem.tsx:81 so valid existing APP, 6AC, HybridApp behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep APP, 6AC, HybridApp consistent at the first read/write boundary shown above.