Expensify Card - Error when try to edit the limit of the first assigned card

[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: v9.3.73-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: #86420
Email or phone of affected tester (no customers): applausetester+rg_72@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 / Chrome, Android 13 / Xiaomi Poco F5, iOS 15.8.3 / iPhone 7 Plus
App Component: Workspace Settings

Action Performed:

Precondition:

• At least have a workspace and Expensify Card feature is enabled
• The BA account is already setup

1. Open the https://staging.new.expensify.com/
2. Navigate to Workspace > Expensify Card
3. Assign or issue virtual card to any member
4. Switch to Expensify Classic (OD), and set the previous assigned Expensify Card's limit to $0
5. Switch back to ND and navigate to Expensify Card. The card with limit $0 appears in the list
6. Open it and try to edit the Card limit

Expected Result:

User can navigate to edit limit, edit name, and edit limit type without errors.

Actual Result:

Error when trying to edit the limit of the first assigned card with a card limit of $0.
Note:

• The "Not here page" will briefly appear in RHP
• "Oops... something went wrong, and your request could not be completed. Please try again later." will appear in the card list
• User unable to assign another card in ND, need to assign it in OD
• User can edit the limit on the second assigned card

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

[melvin-bot]

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

[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: #86420 - "Show admin-zeroed Expensify Cards on the workspace card page" by @MelvinBot (High confidence)
Related Issues: #82466

Recommendation: REVERT

PR #86420 introduced the ability to show admin-zeroed ($0 limit) Expensify Cards in the workspace card management view, but the feature has a regression: navigating to edit the limit on a deactivated (admin-zeroed) card triggers a "Not here page" flash and an API error ("Oops... something went wrong"), and users cannot assign new cards through the ND interface afterward.

Assigned: @MelvinBot (PR author), @sobitneupane, @grgia (approving reviewers)
Labels: DeployBlockerCash kept (frontend App PR caused this); no label changes made.

Detailed Analysis

Evidence

• The issue body explicitly links PR Show admin-zeroed Expensify Cards on the workspace card page #86420 as the source of the regression (Bug source: Pull Request QA execution, with the PR URL in the issue template field).
• The melvin-bot auto-comment also confirms: "You have been assigned to this deploy blocker because you recently merged this PR: Show admin-zeroed Expensify Cards on the workspace card page #86420".
• The bug is staging-only (version v9.3.73-0) and not present in production, consistent with a recently merged staging PR.
• PR Show admin-zeroed Expensify Cards on the workspace card page #86420 is listed in the StagingDeployCash (Deploy Checklist: New Expensify 2026-05-13 #90410) and was merged on 2026-05-12, immediately before this bug report on 2026-05-13.
• The symptom (error when editing limit/name/limit-type for a card with $0 limit set from OldDot) exactly matches the change surface of this PR.

Verification

The PR modifies these files, all directly implicated in the bug:

• src/libs/CardUtils.ts — adds filterInactiveCardsForWorkspace, modifies filterAllInactiveCards to accept includeDeactivated
• src/pages/workspace/expensifyCard/WorkspaceExpensifyCardDetailsPage.tsx — uses getAllCardsForWorkspace(..., true) to include deactivated cards
• src/pages/workspace/expensifyCard/DynamicExpensifyCardLimitPage.tsx — switches from filterInactiveCards to filterInactiveCardsForWorkspace
• src/pages/workspace/expensifyCard/DynamicExpensifyCardLimitTypePage.tsx — same switch
• src/pages/workspace/expensifyCard/DynamicExpensifyCardNamePage.tsx — same switch
• src/pages/workspace/expensifyCard/WorkspaceExpensifyCardPage.tsx — same switch

Root Cause

When an admin sets a card's limit to $0 in OldDot, the backend transitions the card to STATE_DEACTIVATED. PR #86420 now shows these deactivated cards in the workspace card list (correct goal), and navigating to their details page works.

However, when the admin then taps to edit the card limit (navigates to DynamicExpensifyCardLimitPage), two issues arise:

1. "Not here page" flash: The DynamicExpensifyCardLimitPage (and the Name/LimitType sibling pages) look up the card via cardsList?.[cardID] using the filterInactiveCardsForWorkspace selector. On first render, the Onyx value may not yet be populated for the dynamic route, causing a brief period where card is undefined. Unlike WorkspaceExpensifyCardDetailsPage, these sub-pages have no loading guard — if card is undefined they render no NotFoundPage guard, causing navigation fallthrough to "Not here".

2. API error / "Oops" toast: The DynamicExpensifyCardLimitPage validate function rejects any limit where !Number(values.limit) — which is truthy for 0. This means when the current limit is $0, the form shows an "invalid amount" error and refuses to submit. If the user manages to circumvent this or if the deactivated-card API call is made, the backend likely rejects a limit update on a STATE_DEACTIVATED card, producing the generic error toast visible on the card list page. Additionally, updateExpensifyCardLimit uses optimistic updates that merge the new limit into Onyx; a backend rejection with failureData will put the error onto the card item, causing the error message to appear in the card list.

The feature as merged is incomplete: it surfaces the cards in the list but the edit flow for deactivated cards was not fully handled (the sub-pages have no deactivated-card guards, the validation blocks $0, and the backend may not accept a limit update on a deactivated card).