Amex Direct Feed Cards Remain Unassigned in New Expensify After Migration

[m-natarajan]

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.3..3-8
Reproducible in staging?: Needs Reproduction (Reproduction blocked)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @Leeckhart
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. In Classic: Navigate to Settings → Domains → [Domain Name] → [Workspace] → Settings
2. Set and save the workspace as the preferred workspace
3. Same process applied successfully to all other card feeds (e.g., Chase)
4. In New Expensify: Navigate to Workspaces → [Workspace] → Company Cards → American Express Cards (Direct feed)
5. Observe the card list displayed

Expected Result:

All Amex cards associated with the domain should:
Appear in New Expensify
Be automatically assigned based on existing Classic assignments
Match the behavior of other migrated card feeds

Actual Result:

Only one Amex card is assigned and the remaining 9 Amex cards are unassigned in New Expensify.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

The screenshot for the issue is in Slack thread

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @mallenexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[yatin-italy]

Proposal

Restate the problem this issue is trying to solve.

After migration from Classic to New Expensify, most American Express direct feed cards lose their workspace assignment. In New Expensify, many Amex cards appear unassigned even though they were assigned to the workspace in Classic, while other card feeds migrate and stay assigned correctly.

What is the root cause of that problem?

The root cause is a wrong assumption in src/libs/CardUtils.ts inside the getDomainOrWorkspaceAccountID() function. The function assumes that when domainID exists it should always be used, but this is wrong when preferredPolicy is missing and domainID does not match workspaceAccountID. This causes cards stored under workspaceAccountID during migration to be retrieved using domainID, which directly creates the mismatch.

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

• Update the logic in src/libs/CardUtils.ts to match how feeds are filtered.
• Use domainID only when preferredPolicy exists.
• If preferredPolicy is missing, use domainID only when it matches workspaceAccountID.
• Otherwise, always fall back to workspaceAccountID.

File: src/libs/CardUtils.ts
Change: Update getDomainOrWorkspaceAccountID

function getDomainOrWorkspaceAccountID(
    workspaceAccountID: number,
    cardFeedData: CardFeedData | undefined,
): number {
    if (cardFeedData?.preferredPolicy && cardFeedData.domainID) {
        return cardFeedData.domainID;
    }

    if (cardFeedData?.domainID && cardFeedData.domainID === workspaceAccountID) {
        return cardFeedData.domainID;
    }

    return workspaceAccountID;
}

What alternative solutions did you explore? (Optional)

• Setting preferredPolicy during migration was rejected because it needs backend and migration changes.
• Changing card storage to always use domainID was rejected because it risks breaking existing assignments.
• Updating multiple call sites was rejected because it creates inconsistency and higher risk.

[bernhardoj]

Hmm, I'm not sure how we contributor can reproduce this issue. @mallenexpensify do you think this should be checked by an internal employee?

[MelvinBot]

🔍 Issue Analysis

Summary: Amex Direct Feed cards lose their workspace assignment after migration from Classic to New Expensify because of a mismatch between how card feeds are filtered (using preferredPolicy) versus how cards are retrieved (using domainID).

Root Cause: The getDomainOrWorkspaceAccountID() function in CardUtils.ts unconditionally returns domainID if it exists, but the useCardFeeds hook includes feeds based on preferredPolicy matching the policyID. When a migrated Amex feed has preferredPolicy set but an incorrect or stale domainID, the feed appears in the workspace UI (because preferredPolicy matches), but cards are fetched from the wrong Onyx key (because domainID doesn't match where cards are actually stored).

Recommended Fix: Update getDomainOrWorkspaceAccountID() in src/libs/CardUtils.ts to align with the feed filtering logic - only use domainID when preferredPolicy is set (indicating a legitimate domain-level feed), or when domainID matches workspaceAccountID. Otherwise, fall back to workspaceAccountID.

Open Questions

• Why does exactly 1 of 10 Amex cards get assigned while 9 remain unassigned? Is there a partial migration scenario?
• What are the actual domainID and preferredPolicy values in the problematic Amex feed data vs. the workspaceAccountID?
• Does the backend migration correctly set the domainID for Amex Direct feeds, or is there a migration inconsistency?

Detailed Investigation

Root Cause Analysis

The issue stems from inconsistent logic between two operations:

1. Feed Filtering (useCardFeeds.tsx:29-30):

const shouldIncludeFeedPredicate = (combinedCardFeed: CombinedCardFeed) =>
    combinedCardFeed.preferredPolicy ? combinedCardFeed.preferredPolicy === policyID : combinedCardFeed.domainID === workspaceAccountID;

This includes a feed if:

• preferredPolicy exists AND matches policyID, OR
• domainID equals workspaceAccountID

2. Card Retrieval (CardUtils.ts:519-521):

function getDomainOrWorkspaceAccountID(workspaceAccountID: number, cardFeedData: CardFeedData | undefined): number {
    return cardFeedData?.domainID ?? workspaceAccountID;
}

This returns domainID if it exists, regardless of preferredPolicy.

The Mismatch:
When an Amex Direct feed has preferredPolicy set to match the workspace's policyID, the feed shows up in the workspace UI. However, if the feed's domainID points to a different location than where the cards are actually stored (under workspaceAccountID), the card retrieval fails because it's looking in the wrong Onyx key.

Evidence Chain

1. Card feeds are stored in ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_DOMAIN_MEMBER, keyed by domainID/workspaceAccountID
2. useCardFeeds hook filters feeds using preferredPolicy === policyID OR domainID === workspaceAccountID
3. Feed appears in workspace because preferredPolicy matches
4. getDomainOrWorkspaceAccountID() returns domainID (which may differ from workspaceAccountID)
5. useCardsList constructs Onyx key: WORKSPACE_CARDS_LIST${domainOrWorkspaceAccountID}_${feed}
6. Cards stored under workspaceAccountID are not found because lookup uses wrong domainID
7. Result: Feed shows as connected, but most cards appear "unassigned"

Relevant Code

• App/src/libs/CardUtils.ts:519-521 - The getDomainOrWorkspaceAccountID function with overly simple fallback logic
• App/src/hooks/useCardFeeds.tsx:29-30 - Feed filtering that uses preferredPolicy OR domainID matching
• App/src/hooks/useCardsList.tsx:9-11 - Card retrieval that uses the domainOrWorkspaceAccountID to construct Onyx key

Implementation Notes

The proposed fix aligns getDomainOrWorkspaceAccountID() with the filtering logic:

function getDomainOrWorkspaceAccountID(
    workspaceAccountID: number,
    cardFeedData: CardFeedData | undefined,
): number {
    // Use domainID when preferredPolicy is set (legitimate domain-level feed)
    if (cardFeedData?.preferredPolicy && cardFeedData.domainID) {
        return cardFeedData.domainID;
    }

    // Use domainID only if it matches workspaceAccountID (consistent storage)
    if (cardFeedData?.domainID && cardFeedData.domainID === workspaceAccountID) {
        return cardFeedData.domainID;
    }

    // Fall back to workspaceAccountID
    return workspaceAccountID;
}

Edge cases to consider:

• Feeds with preferredPolicy set should use domainID to maintain domain-level card sharing
• Feeds without preferredPolicy but with matching domainID === workspaceAccountID are consistent and safe
• Feeds where domainID differs from workspaceAccountID and preferredPolicy is not set should use workspaceAccountID

---

Next Steps: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.