Travel Billing - Save button keeps loading after Cancel

[jponikarchuk]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.58-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #96943
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Mac

Action Performed:

1. Open the workspace settings.
2. Open Travel and enable Consolidated Travel Billing.
3. Open Monthly spend limit per number.
4. Edit the current monthly spend limit (Reduce travel spend limit) and save
5. Tap Cancel.

Expected Result:

The monthly spend limit edit is canceled and the Save button returns to its normal state.

Actual Result:

After tapping Cancel, the Save button remains in a loading state, even though the edit was canceled.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7238882_1787281515016.Grabando__83.mp4

Issue Owner

Current Issue Owner: @nyomanjyotisa

[MelvinBot]

Proposal

What is the root cause of that problem?

The Save button uses press-loading (an instant spinner shown on press), and on this page nothing ever turns it off when you cancel the "reduce limit" confirmation.

Walking the chain:

1. Tapping Save with a reduced value calls the form's submit, which — because FormProvider defaults shouldShowLoadingImmediatelyOnPress to true — shows the spinner immediately via usePressLoading (setIsPressed(true)) and then runs onSubmit.
2. onSubmit (handleSubmit) detects a reduced limit and calls showConfirmModal(...).then(...). That returns synchronously, so the press handler finishes without throwing — the isPressed spinner stays on by design (it's meant to hand off to a real loading state).
3. When you tap Cancel in the confirm modal, result.action !== ModalActions.CONFIRM, so it returns early and never calls updateTravelBillingMonthlyLimit — meaning no navigation and no Onyx loading flag.
4. usePressLoading only clears isPressed in three ways, none of which happen here:
   • the external isLoading turns true — but updateTravelBillingMonthlyLimit writes to the card-settings collection's pendingFields, not the form's isLoading, so isExternalLoading is always false for this form;
   • the submit callback throws — it doesn't;
   • the screen regains navigation focus (useFocusEffect) — but the confirm modal is a global overlay (useConfirmModal → ModalContext), not a navigation screen, so this page never loses focus and the effect never re-fires.

So isPressed stays true forever and the Save button spins indefinitely. (On the non-reduce path, or after confirming, submitLimit navigates back, which unmounts/blurs the page and resets the state — which is why the bug only shows on Cancel of the reduce-limit warning.)

Code references

• WorkspaceTravelBillingMonthlyLimitPage.tsx:63-82 — handleSubmit opens the confirm modal and returns early on cancel.
• WorkspaceTravelBillingMonthlyLimitPage.tsx:94-103 — FormProvider with no shouldShowLoadingImmediatelyOnPress override (defaults to true).
• FormProvider.tsx:159 and FormProvider.tsx:307-358 — default true and the startWithLoading path.
• usePressLoading.ts:27-57 — the three reset conditions (external isLoading, throw, useFocusEffect).
• useConfirmModal.ts:9-28 — confirm modal is a global overlay, not a navigation screen.
• TravelBilling.ts:669-721 — the update writes pendingFields, never the form isLoading.

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

Disable the instant press-loading on this specific form by passing shouldShowLoadingImmediatelyOnPress={false} to the FormProvider in WorkspaceTravelBillingMonthlyLimitPage. This form's submit either navigates back immediately or opens a confirmation modal — neither needs the instant press spinner, and there's no external Onyx loading state to hand off to. With it off, the button reflects only the (always-false) external loading, so cancelling the warning leaves it in its normal state.

What alternative solutions did you explore? (Optional)

• Reset press-loading when the modal is dismissed — more robust for the general pattern (any FormProvider whose onSubmit opens an overlay modal and the user cancels has this bug), but FormProvider owns isPressed internally and doesn't expose a reset, so this needs a broader usePressLoading/FormProvider change and wider regression testing.
• Reorder the flow so the reduce-limit confirmation is shown before the form submit fires — larger refactor for the same outcome.

---

Confidence & verification

High confidence — the full input → bug → symptom chain is backed by code, and it precisely explains why the spinner sticks only on the reduce-limit Cancel path and not otherwise. I did not runtime-reproduce it: reaching this screen requires an admin on a verified private domain with a business settlement bank account to enable Consolidated Travel Billing, which isn't available in a standard test session.

---

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

---

view run

[melvin-bot]

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

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[nyomanjyotisa]

@MelvinBot’s proposal looks good.\n\n🎀 👀 🎀 C+ reviewed

[melvin-bot]

Triggered auto assignment to @pecanoro, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[pecanoro]

@nyomanjyotisa Sounds good! Feel free to tell Melvin to create the PR!