Company cards - Add card RHP loads infinitely after card admin finishes Plaid flow

[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.7-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: #92740
Email or phone of affected tester (no customers): jsodinjosdjsoinjsiojs@gmail.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:

• User A invites User B to workspace as card admin.
• Perform steps below as card admin (User B).

1. Go to staging.new.expensify.com
2. Go to workspace settings > Company cards.
3. Click Add card > Add card.
4. Select United States > Next.
5. Select Direct feed > Other > Next.
6. Complete Plaid flow.

Expected Result:

Direct feed will be added successfully by card admin.

Actual Result:

Add card RHP loads infinitely after card admin finishes Plaid flow.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7179428_1781304284043.19.mp4

View all open jobs on GitHub

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

[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/a81af1a65666a9f26480d9a8beed3dc3a54d0bd52079275efdac25072e6e9af0

[melvin-bot]

@flodnv recently merged #92740, but they are OOO right now, so I'll auto-assign someone else.

[melvin-bot]

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

Issue Analysis

Root Cause (Medium confidence): The "Add card" RHP shows an infinite spinner because the App is waiting for the newly-created card feed to appear in Onyx, and that update never arrives for a Card Admin. The App-side flow itself is not admin-gated — the spinner is purely waiting on backend data that a card admin never receives.

After Plaid completes, the direct-feed flow renders BankConnection, which fires the ImportPlaidAccounts write and then renders a full-screen ActivityIndicator until the new feed shows up in the company-cards collection. The clear condition (isNewFeedConnected) only flips to true once the backend populates the domain-member feed data. For a card admin, that data flip never lands, so the spinner runs forever.

This is almost certainly introduced by #92740 ("Add Card Admin workspace access") — the repro requires the brand-new CARD_ADMIN role, which is why it's "N/A in production." That PR correctly grants card admins write access to Company Cards on the frontend (COMPANY_CARDS: WRITE in the role bundle), so they can now reach a flow whose backend completion step does not yet recognize the new role.

Where the fix likely lives: Outside the App repo. The frontend logic that drives this spinner has no admin-only gate. The missing piece is the backend command that creates/links the feed and pushes the resulting domain-member update to the policy's members — it appears not to deliver that update (or rejects the request) for a non-admin CARD_ADMIN. This needs an internal engineer with backend access to confirm and fix (check whether the feed-import / company-cards-enable command and its Pusher/domain-member push accept the CARD_ADMIN role).

A possible App-side mitigation for the deploy blocker (product decision): until the backend supports card admins adding new feeds, restrict card admins to managing existing feeds, or revert #92740. Note there are sibling deploy blockers from the same PR (see below), which may argue for a revert.

Investigation details & evidence

Spinner & clear condition (f568f8b):

• The infinite spinner: BankConnection/index.tsx:227-233 — for the Plaid branch this ActivityIndicator renders until isNewFeedConnected is true.
• The clear effect: BankConnection/index.tsx:154-168 — only calls Navigation.closeRHPFlow() once isNewFeedConnected flips.
• Derivation of isNewFeedConnected: CardUtils.ts:1072-1086 — true only when the company-cards collection gains the new feed. That data comes from the backend response / domain-member Pusher push, not from the ImportPlaidAccounts optimistic data.

Why it's not the new access wrapper: PR #92740 wrapped these pages in AccessOrNotFoundWrapper with policyFeatureAccess=WRITE. A card admin on a Control workspace passes that check, and the full-screen loader there is gated on isPolicyEmpty (AccessOrNotFoundWrapper.tsx:188), so once the policy is loaded the wrapper renders children. The ADMIN access variant is also filtered out when policyFeature is set (AccessOrNotFoundWrapper.tsx:195). So the wrapper is not the source of the hang.

Role permissions: Card admin gets COMPANY_CARDS: WRITE, but only on Control policies (PolicyUtils.ts:157-196).

No App-side admin gate in this path: useIsAllowedToIssueCompanyCard is only used by the assign flow, not the add-new/Plaid flow, so it's not involved.

Could not confirm with logs: VictoriaLogs access isn't available in this environment. To raise confidence to High, an engineer should search staging logs for the card admin's ImportPlaidAccounts / OpenPolicyAddCardFeedPage requests (tester User B: jsodinjosdjsoinjsiojs@gmail.com) and check whether the command was rejected or returned success without the sharedNVP_private_domain_member_<domainID> feed data.

Alternative explanation considered: A Pusher-channel scoping issue (domain-feed updates only pushed to admins) would produce the same symptom even if the command succeeded — also a backend/infra fix.

Likely related (same PR #92740 / Card Admin feature)

• [Workspace Roles] Release 2: Card Admin — Company Cards page guards and write controls #90501 — the feature issue this flow belongs to ("Card Admin — Company Cards page guards and write controls").
• Card admin can click Learn more on Get the Expensify Card banner which enables Expensify Card #93506 — DeployBlockerCash: card admin can enable Expensify Card via "Learn more".
• Expensify Card - Error after renaming card, changing limit and limit type as card admin #93500 — DeployBlockerCash: error renaming card / changing limit as card admin.

These sibling blockers suggest the card-admin write access exposed several flows the backend/UX doesn't fully support yet.

---

This appears to require a fix outside the Expensify/App repo (backend). An internal engineer with backend access should confirm the CARD_ADMIN role is honored by the feed-import command and its domain-member push. Reply with @MelvinBot <feedback> to refine this analysis.

[ShridharGoel]

Seems to be BE issue