[Due for payment 2025-05-22] [$250] Expense - First expense show "card" icon after reviewing duplicates and submit another expense

[mitarachim]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 9.1.42-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from TestRail: #61273
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team
Device used: Mac 15.3 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Log in with Expensifail account.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Submit two expenses with the same amount and merchant.
4. Click on the expense preview.
5. Click Review duplicates.
6. Click Keep this one on any expense preview.
7. Click Confirm on the confirmation page.
8. Click + > Create expense > Manual.
9. Submit another manual expense.

Expected Result:

The first expense will show "cash" icon instead of "card" icon.

Actual Result:

The first expense show "card" icon instead of "cash" icon after reviewing duplicates and submit another expense.
It changes to "cash" icon after opening the transaction thread.
On small screen, it shows "card" text.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6825170_1746677346126.20250508_120252.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021920535971542882679
• Upwork Job ID: 1920535971542882679
• Last Price Increase: 2025-05-08

Issue Owner

Current Issue Owner: @NicMendonca

[melvin-bot]

Triggered auto assignment to @NicMendonca (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.

[melvin-bot]

Triggered auto assignment to @madmax330 (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.

[madmax330]

I think this is an FE issue

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~021920535971542882679

[melvin-bot]

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

[melvin-bot]

📣 @Ganzz4! 📣
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>

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[yuwenmemon]

Back-end issue, not a blocker.

[bradyrose]

Proposal

Please re‑state the problem that we are trying to solve in this issue.

After reviewing duplicate expenses and then immediately submitting a new manual expense, the first expense in the list still shows the “card” icon instead of “cash” until the transaction thread is reopened.

What is the root cause of that problem?

Our icon renderer reads each transaction’s paymentType only from the persisted Redux state on initial load. The duplicate‑review flow doesn’t update paymentType in local state, so the UI continues rendering the stale “card” icon until a full re‑mount.

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

1. Optimistically update paymentType in Redux when the user confirms “Keep this one”:

    // src/pages/DuplicateReview/KeepThisOneButton.tsx
    import { useDispatch } from 'react-redux';
    import { updateTransactionType } from '../../actions/transactionActions';
    import * as api from '../../lib/api';
    import Navigation from '../../libs/Navigation';
   
    export default function KeepThisOneButton({ transactionID }) {
        const dispatch = useDispatch();
   
        const onPress = async () => {
            await api.reviewDuplicates(transactionID, 'keep');
            dispatch(updateTransactionType(transactionID, 'cash'));  // ← update locally
            Navigation.goBack();
        };
   
        return <Button onPress={onPress}>Keep this one</Button>;
    }
   

2. Implement the action and reducer to patch state immediately:

    // src/actions/transactionActions.ts
    export const UPDATE_TRANSACTION_TYPE = 'UPDATE_TRANSACTION_TYPE';
    export function updateTransactionType(id: string, type: 'cash' | 'card') {
        return { type: UPDATE_TRANSACTION_TYPE, payload: { id, type } };
    }
   
    // src/reducers/transactions.ts
    import { UPDATE_TRANSACTION_TYPE } from '../actions/transactionActions';
   
    export default function transactions(state = [], action) {
        switch (action.type) {
            case UPDATE_TRANSACTION_TYPE:
                return state.map(tx =>
                    tx.id === action.payload.id
                        ? { ...tx, paymentType: action.payload.type }
                        : tx
                );
            default:
                return state;
        }
    }
   

3. Ensure the icon component reads the updated paymentType from Redux:

    // src/components/TransactionItem.tsx
    import { useSelector } from 'react-redux';
    import CashIcon from '../icons/CashIcon';
    import CardIcon from '../icons/CardIcon';
   
    export default function TransactionItem({ transactionID }) {
        const tx = useSelector(state =>
            state.transactions.find(t => t.id === transactionID)
        );
        const Icon = tx.paymentType === 'cash' ? CashIcon : CardIcon;
        return (
            <View style={styles.row}>
                <Icon style={styles.icon} />
                {/* ...other fields... */}
            </View>
        );
    }
   

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

• Duplicate‑review + new expense: dispatch UPDATE_TRANSACTION_TYPE, then verify the icon toggles to cash immediately.
• No review flow: original transactions still render the card icon.
• Rapid sequence: multiple review actions in a row don’t produce stale UI.

What alternative solutions did you explore? (Optional)

• Forcing a full list refetch from the server (adds latency).
• Remounting the entire list view on review (janky UX).

By updating paymentType in local Redux state as soon as the user confirms “Keep this one,” we ensure the correct “cash” icon displays immediately—eliminating the stale “card” flash.

[luacmartins]

PR is merged #61738

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.1.45-21 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Fix icon type #61738

If no regressions arise, payment will be issued on 2025-05-22. 🎊

For reference, here are some details about the assignees on this issue:

• @c3024 requires payment through NewDot Manual Requests

[melvin-bot]

@c3024 @NicMendonca @c3024 The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

[c3024]

BugZero Checklist:

• [Contributor] Classify the bug:

Bug classification

Source of bug:

• 1a. Result of the original design (eg. a case wasn't considered)
• 1b. Mistake during implementation
• 1c. Backend bug
• 1z. Other:

Where bug was reported:

• 2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
• 2b. Reported on staging (eg. found during regression or PR testing)
• 2d. Reported on a PR
• 2z. Other:

Who reported the bug:

• 3a. Expensify user
• 3b. Expensify employee
• 3c. Contributor
• 3d. QA
• 3z. Other:

• [Contributor] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.

  Link to comment:

• [Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.

  Link to discussion:

• [Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.

Regression Test Proposal Template

• [BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.

  Link to issue:

Regression Test Proposal

Precondition:

Test:

Do we agree 👍 or 👎