[Due for payment 2026-05-20] Android - Expense - Unable to delete expense, saved search, category, tag etc

[jponikarchuk]

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.73-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: #89609
Email or phone of affected tester (no customers): sdsdjoijdoisnjodis@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Samsung Galaxy S25 FE / Android 16
App Component: Money Requests

Action Performed:

1. Launch Expensify app.
2. Go to workspace chat.
3. Create an expense.
4. Open the expense report.
5. Tap More > Delete > Delete.

Expected Result:

Expense can be deleted.

Actual Result:

Expense cannot be deleted.
This issue also happens in many areas of the app - delete save search, remove member, delete category, tag, distance rate, tax, per diem rate etc

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @abzokhattab

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #89609

[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.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #90358 - "Refactor ReanimatedModal/index.tsx to follow Rules of React and compile with React Compiler" by @roryabraham (High confidence)
Related Issues: N/A

Recommendation: REVERT

PR #90358 introduced a regression on Android where onModalHide never fires after a confirmation modal is dismissed, causing all confirmation-gated actions (delete expense, remove member, delete category, delete tag, etc.) to silently fail.

Assigned: @roryabraham (PR author), @abzokhattab @carlosmiceli (approving reviewers)
Labels: DeployBlockerCash kept (frontend App bug). No label changes made.

Details

Evidence

• The bug is reproducible on staging only (not production), and version 9.3.73-0 is the staging version
• All affected operations (delete expense, delete saved search, remove member, delete category, tag, distance rate, tax, per diem rate) share one common pattern: they use the global showConfirmModal() API, which resolves its Promise only inside handleModalHide in ConfirmModalWrapper
• ConfirmModalWrapper.handleModalHide calls closeModal({action: closeAction}) which resolves the Promise; if this never runs, the .then() callback (which actually executes the delete/remove API call) is never reached
• Bug is Android-native only, which is consistent with the Android-specific onModalHide path in ReanimatedModal

Verification

Affected file: src/components/Modal/ReanimatedModal/index.tsx

PR #90358 modifies exactly this file, removing useCallback wrappers from onOpenCallBack and onCloseCallBack.

Root Cause

PR #90358 is a React Compiler compliance refactor that removes useCallback wrappers from all functions inside ReanimatedModal, including onCloseCallBack and onOpenCallBack. These callbacks are passed to the native Container component (src/components/Modal/ReanimatedModal/Container/index.tsx), where they are captured in useMemo-computed Reanimated Keyframe animations:

const Exiting = useMemo(() => {
  const AnimationOut = new Keyframe(getModalOutAnimation(animationOut));
  return AnimationOut.duration(animationOutTiming).withCallback(() => {
    "worklet";
    scheduleOnRN(onCloseCallBack);
  });
}, [animationOutTiming, onCloseCallBack, animationOut]);

Because onCloseCallBack is now a plain function (new reference on every render, not stabilized by useCallback), this useMemo recomputes and creates a new Exiting animation keyframe on every render. Replacing the exiting prop on an Animated.View while an exit animation is in progress on Android causes the animation to be interrupted or the completion callback (scheduleOnRN(onCloseCallBack)) to never fire.

On Android, onModalHide is called exclusively from onCloseCallBack (due to unreliable onDismiss). When onCloseCallBack never fires:

1. onModalHide is never called
2. ConfirmModalWrapper.handleModalHide never runs
3. closeModal({action: closeAction}) never resolves the Promise
4. The .then() handler that runs the delete/remove action is never reached
5. The user sees the modal close (the UI updates because isVisible becomes false), but the actual operation silently does not execute

[MelvinBot]

Proposal

What is the root cause of that problem?

PR #89609 removed the narrow-layout guard from dismissToSuperWideRHP. Previously, on narrow/mobile layouts, this function called dismissModal(options) directly. Now it unconditionally delegates to navigateBackToLastSuperWideRHPScreen → dismissToModalStack.

The problem is in dismissToModalStack at line 946-948: when RIGHT_MODAL_NAVIGATOR exists in the root state but its .state property is not hydrated (which can happen on narrow layouts), the function silently returns without calling dismissModal or the afterTransition callback. This leaves the user stuck — the confirmation/action screen never dismisses, making it appear that delete (and similar actions) don't work.

This affects all flows that use dismissToSuperWideRHP, which is why the bug manifests across delete expense, saved search, categories, tags, distance rates, taxes, per diem rates, etc.

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

Restore the narrow-layout guard in dismissToSuperWideRHP that was removed by PR #89609:

function dismissToSuperWideRHP(options) {
    if (getIsNarrowLayout()) {
        dismissModal(options);
        return;
    }
    navigateBackToLastSuperWideRHPScreen(options);
}

The Super Wide RHP concept doesn't apply on narrow/mobile layouts, so the direct dismissModal call is the correct behavior there. The original PR's intent to clean up code was valid for wide layouts, but the narrow-layout path still needs special handling.

Investigation details

Evidence chain:

1. dismissToSuperWideRHP is called by ~13 call sites including navigateBackOnDeleteTransaction and various workspace settings delete flows
2. On narrow layout, dismissToModalStack checks for rhpState at Navigation.ts:944-948 — if the RHP route's .state is unhydrated, it returns without action
3. The old guard (getIsNarrowLayout() → dismissModal) bypassed this entirely, which is why the bug only appeared after the guard was removed
4. Reproducible in staging (where Remove narrow-layout special case from dismissToSuperWideRHP #89609 is deployed) but not production (where the guard still exists)

---

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.