[Due for payment 2026-07-23] Expensify Card - Save button loads infinitely after dismissing Change card limit modal

[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.34-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #92498
Email or phone of affected tester (no customers): applausetester+ssndjois2jd1@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Workspace has at least one Expensify Card.

1. Go to staging.new.expensify.com
2. Go to workspace settings > Expensify Card.
3. Open Expensify Card.
4. Click Amount.
5. Change the amount to 0 > Save.
6. Click Cancel.

Expected Result:

Save button will not load infinitely.

Actual Result:

Save button loads infinitely after dismissing Change card limit modal.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7208120_1784037028320.7.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7208120

Issue Owner

Current Issue Owner: @OlGierd03

[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/417dc3c01159795c3aeee3922789e0fba3f0d65536e2ab95c4aa45f95fb0da82

[melvin-bot]

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

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

[OlGierd03]

That's the another place to opt-out the same way as in the fix for #96055. Fixing it right away

[MelvinBot]

Proposal

What is the root cause of that problem?

Regression from #92498, which added an immediate "press spinner" to form submit buttons via the new usePressLoading hook.

When you set the limit to 0 and press Save, FormProvider flips its local isPressed flag to true (spinner on) and then calls the page's onSubmit. For a limit of 0, newAvailableSpend is <= 0, so submit opens a confirmation modal and returns early — it never calls the API, so no Onyx loading state is ever set.

usePressLoading only clears isPressed in two ways, and neither fires on this path:

1. Hand-off when the external isLoading turns true (usePressLoading.ts:31-33) — never happens because the early return sets no loading state.
2. useFocusEffect reset when the screen regains focus (usePressLoading.ts:48-55) — never happens because the confirm modal is a global overlay rendered through useConfirmModal / ModalContext, not a React Navigation screen. The page never loses focus, so dismissing the modal never re-triggers the focus effect.

Result: after Cancel, isPressed stays true and the Save button spins forever.

Why "change to 0" is the trigger + confirmation this is App-only

• A limit change where newAvailableSpend > 0 goes straight to updateCardLimit → goBack(), so the page unmounts and there's no stuck spinner. Setting the limit to 0 (or otherwise driving newAvailableSpend <= 0) is what routes through the confirmation modal.
• Confirming the modal also calls goBack() (unmount → no stuck spinner). Only Cancel leaves the page mounted with isPressed === true.
• FormProvider drives the spinner itself via the hook (FormProvider.tsx:284, 318-326); FormWrapper intentionally sets shouldShowLoadingImmediatelyOnPress={false} on the button (FormWrapper.tsx:202) so the button only reflects the hook's state.
• This is entirely in Expensify/App (frontend). No backend change is involved.

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

The PR's own design already excludes "consumers who make early returns via onSubmit" from the instant spinner — this form (whose onSubmit early-returns into a confirm modal) was simply not excluded.

Add an opt-out to FormProvider mirroring the existing shouldShowLoadingImmediatelyOnPress prop on FormAlertWithSubmitButton (default true), thread it into the usePressLoading call at FormProvider.tsx:284 so that when disabled the button's loading state comes only from formState?.isLoading/Onyx, then set shouldShowLoadingImmediatelyOnPress={false} on the FormProvider in DynamicExpensifyCardLimitPage.

Any other FormProvider form whose onSubmit can open a cancelable confirm modal without setting a loading state is vulnerable to the same stuck spinner and should get the same opt-out.

Given this is a deploy blocker, reverting #92498 is the fast fallback if a targeted fix can't be verified in time.

What alternative solutions did you explore? (Optional)

• Reset isPressed whenever the global modal stack closes (more robust/general, but touches shared modal/hook plumbing — riskier for a deploy blocker).
• Have the card-limit submit set/clear a local loading state around the modal so the hook's hand-off path fires — more code in the page than the opt-out.

---

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

[rlinoz]

CP here https://expensify.slack.com/archives/C07J32337/p1784045474204599

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.