[Due for payment 2026-07-13] iOS - Report-Unable to cancel payment or delete expense. Nothing happens after confirmation

[applause-bot]

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.4.17-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/13176702/test-cases/41236792
Email or phone of affected tester (no customers): fischer9966+062226adm@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: iPhone 17 Pro / 26.5.1
App Component: Money Requests

Action Performed:

Precondition:

1. Create new Admin account with Gmail
2. Create Collect workspace, set Workflows to enabled
3. Enable Workflows > Delay submissions and set it to Manually
4. Enable Approvals in Workflows and set Admin as Approver
5. Enable Payments and connect bank account (eq Regions Bank, Savings account 1111)

Steps > Cancel payment:

1. Create new report in workspace and add expense
2. Submit report and approve it
3. Pay report with bank account
4. Open report and tap "More" > "Cancel payment"
5. Tap "Cancel Payment" in confirmation screen

Steps > Delete expense:

1. Create new report in workspace and add expense
2. Submit report
3. Open report and tap "More" > "Delete"
4. Tap "Delete" in confirmation screen

Expected Result:

User can successfully cancel payment or delete expense

Actual Result:

User can not cancel payment or delete expense. Nothing happens after user click "Cancel Payment" or "Delete" in confirmation screen.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7188143_1782176987514.iOS-Unable-Cancel-Payment.mp4

Bug7188143_1782178772928.iOS-Unable-delete-expense.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7188143

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/65862ce5032534fa8378b0c7a2e31bdd7a2a78103d6a2536038ba9fcad8b7173

https://platform.applause.com/services/links/v1/external/be8a981cf41c4118bb877526b3bfff3f3d56dde17aaf9e9699db38ee79a5f4ec

[melvin-bot]

Triggered auto assignment to @roryabraham (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

⚠️ Confidence: Medium. The mechanism below is well-evidenced in code (high confidence). The exact regressing PR is not yet pinned — see "What changed" — and this needs on-device iOS verification since it doesn't reproduce on web/Android.

TL;DR: On iOS, tapping Cancel Payment / Delete silently does nothing because both confirmations run through the new global-modal system (showConfirmModal), where the confirm action only fires after the modal's onModalHide callback resolves the promise. On iOS that callback is not firing for these flows, so the code after await showConfirmModal(...) never runs.

What is the root cause of that problem?

Both broken flows are showConfirmModal callers that gate their action on the resolved promise:

• Cancel Payment — useLifecycleActions.tsx:373-387
• Delete expense / report — useExpenseActions.ts:483-493 and :544-553

Both do const result = await showConfirmModal(...) then if (result.action !== ModalActions.CONFIRM) return; before calling cancelPayment(...) / the delete action. Neither passes isConfirmLoading.

In ConfirmModalWrapper.tsx:23-48, when isConfirmLoading is not set, handleConfirm only calls setIsVisible(false). The promise is resolved exclusively later, inside handleModalHide → closeModal({action: CONFIRM}), which runs only when the modal fires onModalHide.

On iOS, onModalHide fires only via React Native core <Modal>'s onDismiss (ReanimatedModal/index.tsx:239-244), which requires the exit animation to complete and flip visible true→false. If that chain doesn't complete, onModalHide never fires, closeModal is never called, and the awaited promise hangs forever — so the confirm action silently never runs. Because ModalContext.tsx only removes the modal from the stack inside closeModal (itself called from onModalHide), nothing self-heals.

This is iOS-only (matches the report) and affects every showConfirmModal caller that relies on onModalHide to resolve, but Cancel Payment and Delete are the two flows QA exercised here.

What changed (regression window) — not yet pinned

• The showConfirmModal migration for these flows is old (April–May, already in production), so the architecture itself isn't new in this release.
• No ConfirmModalWrapper / ModalContext / ConfirmModal / ReanimatedModal source file was directly edited in the 9.4.17 staging window — so this is most likely a shared-infra / dependency change (RN core <Modal>, Reanimated, keyboard, or Onyx) that perturbed the iOS modal exit-animation → onDismiss timing.
• Supporting signal: this release has a cluster of iOS modal/focus/input deploy blockers ([Due for payment 2026-07-03] [$250] [Due for payment 2026-07-01] [Due for payment 2026-06-30] iOS - Expense - App returns to Spend briefly after closing confirm page on Workspaces tab #94271, [Due for payment 2026-07-03] [Due for payment 2026-07-01] [$250] [Due for payment 2026-06-30] Expenses - All fields are unfocused after every input when tracking expense with FAB #94273, [Due for payment 2026-07-03] [Due for payment 2026-07-01] [Due for payment 2026-06-30] Android & iOS - Expense - Description field is not visible when focused #94274, Spend - "Close" option is not displayed in the Download PDF modal #94278), pointing at a shared modal/keyboard regression rather than four independent bugs.
• Next step to pin it: bisect on an iOS build across the 9.4.17 StagingDeployCash PRs, prioritizing any RN / react-native-reanimated / keyboard / modal-infra bumps. A git bisect against the production (9.4.16) cut is the fastest route — I couldn't do this here (shallow, tagless checkout).

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

Decouple the confirm action from the modal hide animation so the awaited promise resolves the moment the user confirms, instead of waiting for iOS onModalHide. In ConfirmModalWrapper's non-isConfirmLoading branch, resolve the confirm result on the button press itself (the same way the isConfirmLoading branch already calls resolveModal({action: CONFIRM})), while still hiding the modal and ensuring it is removed from the modal stack. That makes the action fire regardless of whether the iOS exit animation/onDismiss completes.

If the underlying regression is a shared modal-infra change (see "What changed"), reverting that PR is the faster deploy-blocker unblock; the ConfirmModalWrapper change above is the durable fix that prevents this class of silent hang from recurring.

What alternative solutions did you explore? (Optional)

Have handleConfirm/handleCancel call closeModal({action}) directly (resolves the promise and slices the modal off the stack in one step), accepting the loss of the exit-fade animation. Simpler and fully robust, but a slightly more abrupt dismiss.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94281) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[hungvu193]

@MelvinBot find the offending PR