PayMoneyRequest 411 (support token) silently shows infinite spinner instead of error message

[melvin-bot]

Problem

When PayMoneyRequest is rejected by Bedrock with jsonCode: 411 - InsufficientPrivileges - "support token", the New Expensify client silently suppresses the retry and leaves the user stuck on a blank infinite loading/spinner screen with no error message surfaced.

This was observed for pbedard@trucknroll.com (accountID 21399557) attempting to reimburse Report R00FLkiYoDIa on May 28–29, 2026. Client logs confirm:

"Supportal insufficient permissions; suppressing retry"

The AnimatedSettlementButton spinner (driven by usePaymentAnimations.startAnimation) never calls stopAnimation because the optimistic action never resolves cleanly — Bedrock returns 411, no Onyx update is shipped, and lastUpdateID stays at 0 on all subsequent requests.

Expected Behavior

When PayMoneyRequest fails with a 411 (or any non-retryable error), the user should see a visible error message — either a toast notification or a Red Brick Road (RBR) error on the report — explaining why the payment failed, and the spinner should stop.

Actual Behavior

• The settlement button enters a spinner/loading state
• Bedrock returns jsonCode: 411
• The client recognizes the "support token" / Supportal shape and suppresses the retry without showing any error
• The spinner runs indefinitely
• The user has no way to know what went wrong or what to do next

Root Cause

In src/libs/actions/IOU/PayMoneyRequest.ts, payMoneyRequest() issues the PAY_MONEY_REQUEST write command. The only error surface is failureData written into the IOU report's errors map — there is no toast. When the server returns 411, the API layer's "suppress retry" branch suppresses both the retry and any visible error feedback.

Fix

The "suppress retry" branch for Supportal/support-token 411 responses should still write a user-visible error (toast or RBR) before suppressing the retry, so the user knows the payment was rejected and why.

At minimum, stopAnimation should be called on the AnimatedSettlementButton so the spinner does not run indefinitely.

Impact

• Users stuck on an infinite blank loading screen with no recovery path
• Observed in production: pbedard@trucknroll.com on May 28–29, 2026 (request IDs: a02e28f8dfb34e00-LAX, a037faa5d99ac2f1-SJC)

[MelvinBot]

Proposal

What is the root cause of that problem?

The premise in the issue body doesn't match the current code — there is already a Supportal-411 handler that does show a user-visible modal (not "silent"), and the pay button spinner is time-based, not API-bound, so it can't run indefinitely from the API alone. The reported symptoms therefore need a different root cause than the one proposed in the body.

What the code actually does today:

• src/libs/Middleware/SupportalPermission.ts:14-33 intercepts responses where isSupportAuthToken() && response.jsonCode === 411 && message.includes('You are not authorized to take this action when support logged in.'), sets shouldRetry = false, and calls showSupportalPermissionDenied({command}).
• src/libs/actions/App.ts:951-953 writes the payload to ONYXKEYS.SUPPORTAL_PERMISSION_DENIED.
• src/components/SupportalPermissionDeniedModal.tsx observes that key and renders a confirm modal globally via AuthScreens.tsx:159.
• The "spinner" is the AnimatedSettlementButton Keyframe at AnimatedSettlementButton.tsx:74-86 — duration CONST.ANIMATION_PAID_DURATION + CONST.ANIMATION_PAID_BUTTON_HIDE_DELAY — and its onButtonExitComplete always calls finishAnimationAndReset → onAnimationFinish → stopAnimation. There is no path where the API response keeps this Keyframe alive.
• failureData is applied for any non-200 jsonCode except 460 — see OnyxUpdates.ts:48-66 — so the optimistic settle on the IOU report is rolled back and errors is written on 411 as well.

So the body's claims "silently suppresses the retry … no error message", "spinner runs indefinitely because the optimistic action never resolves", and "no Onyx update is shipped" are all contradicted by the code.

The plausible real gaps that could match the reported symptom are:

1. Message-string brittleness. The Supportal modal only fires when the response message contains the exact substring "You are not authorized to take this action when support logged in." (SupportalPermission.ts:18). Any 411 from Bedrock for a support session with even a slightly different message (e.g. "Insufficient privileges" or "support token required") falls through, shouldRetry is not cleared, the request is requeued, and the user sees no modal. The original comment phrasing "411 - InsufficientPrivileges - 'support token'" is a different message than the substring the middleware matches — that is the most concrete failure mode I can point to from the code alone.
2. Non-supportal 411. If a 411 reaches a regular (non-supportal) session, the middleware never fires (the isSupportAuthToken() guard at line 18). The user only sees the RBR error from failureData; there is no toast surfacing it.

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

Recommendation

Broaden the Supportal-411 detection so it doesn't depend on an exact message substring:

• In src/libs/Middleware/SupportalPermission.ts, drop or relax the message.includes(...) check — any jsonCode === 411 arriving while isSupportAuthToken() is true is an unauthorized supportal command by construction; the message string shouldn't gate the modal.
• For non-supportal 411 (case 2 above), prefer a backend fix to return a more appropriate code (403/4xx with a usable message), since the App side has no way to distinguish "real" 411s from supportal ones without the support-token guard.
• If reproduction logs confirm the modal is firing but is being dismissed silently or not surfacing, the next place to look is useConfirmModal (SupportalPermissionDeniedModal.tsx:11-28) and whether isSupportalModalOpenRef is stuck true from an earlier denial.

What alternative solutions did you explore? (Optional)

Alternatives considered

• Adding a toast in PayMoneyRequest.ts as the issue body suggests — this duplicates the modal that already exists and doesn't fix the underlying detection gap.
• Calling stopAnimation from the middleware — unnecessary; the Keyframe self-terminates after ANIMATION_PAID_DURATION, so the spinner already stops on its own regardless of API outcome.

Notes on the reported evidence

I cannot confirm the production symptoms from code alone — the request IDs (a02e28f8dfb34e00-LAX, a037faa5d99ac2f1-SJC) and accountID 21399557 would need to be checked against logs to verify (a) whether the middleware fired, (b) which exact message Bedrock returned, and (c) whether the modal Onyx key was written. A log investigation keyed on "Supportal insufficient permissions; suppressing retry" around 2026-05-28/29 plus the 411 response payload would settle whether the issue is the message-substring gap or something else.

---

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

[ahsan3219]

Proposal

What is the root cause of the problem?

The root cause is a message-string matching brittleness in src/libs/Middleware/SupportalPermission.ts. The middleware intercepts 411 responses only when the response message contains the exact substring:

"You are not authorized to take this action when support logged in."

The reported production failure shows Bedrock returning a 411 with a message shaped like "InsufficientPrivileges - support token" — which does not match that hardcoded substring. As a result, the middleware's guard condition fails silently:

• shouldRetry is never set to false
• showSupportalPermissionDenied() is never called
• The SupportalPermissionDeniedModal never renders
• The request gets requeued and retried in a loop
• The AnimatedSettlementButton keeps cycling through its animation because no clean resolution path (success or acknowledged failure) is reached

The issue title says "infinite spinner" — this is consistent with a retry loop that never terminates cleanly and never writes a user-visible error, rather than the animation keyframe itself running indefinitely.

What changes should be made to solve the problem?

The fix should be in src/libs/Middleware/SupportalPermission.ts. Instead of matching on the full hardcoded message string, broaden the 411 interception condition to match on any response that satisfies isSupportAuthToken() && response.jsonCode === 411, regardless of the message body. The current exact-string check is too brittle and any variation in Bedrock's error message wording causes the entire error handling path to be skipped.

Concretely:

// Before (brittle — misses any variation in Bedrock's message wording)
if (
  isSupportAuthToken() &&
  response.jsonCode === 411 &&
  message.includes('You are not authorized to take this action when support logged in.')
) { ... }

// After — catch all support-token 411s regardless of message wording
if (isSupportAuthToken() && response.jsonCode === 411) { ... }

This ensures that any 411 received during a support session always:

1. Sets shouldRetry = false to stop the retry loop
2. Calls showSupportalPermissionDenied({command}) to surface the modal
3. Stops the spinner by allowing the animation to reach its onButtonExitComplete → finishAnimationAndReset path cleanly

As a secondary safeguard, failureData should also be confirmed to write a visible RBR error on the IOU report for any 411 that slips through in non-supportal sessions, which is already partially handled by OnyxUpdates.ts but worth verifying covers the PayMoneyRequest command specifically.

What alternative solutions were explored?

• Adding a separate toast notification on 411 was considered, but the existing SupportalPermissionDeniedModal is already the correct UX surface — the real problem is that it never fires due to the string mismatch, so fixing the guard condition is cleaner than adding a second error channel.
• Calling stopAnimation directly from the API error handler was considered as a quick fix for the spinner, but this treats the symptom rather than the cause. The retry loop not terminating is the root issue; stopping the animation without stopping the retries would still leave the user in a broken state.

[melvin-bot]

📣 @ahsan3219! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>