[Due for payment 2026-04-07] Report - Inconsistent size of "Review duplicates" and "More" options while resolving duplicates

[lanitochka17]

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.47.0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-13048/folder/13176704/41236823/1280344322
Email or phone of affected tester (no customers): ibellicotest+2250@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app)
App Component: Money Requests

Action Performed:

Prerequisite: Account has at least one workspace.

1. Open the Expensify app.
2. Open any workspace chat.
3. Create two similar manual expenses.
4. Create another report and add an expense similar to the previous ones.
5. Open the report with two expenses.
6. Note that "Review Duplicates" button is bigger than "More" button.
7. Open any of both expenses.
8. Note that now, both buttons are almost equal on size. "Review Duplicates" button is smaller, and "More" button is bigger,
9. Navigate to the report created on step 4.
10. Note that once again, "Review Duplicates" button is displayed bigger than "More" button.

Expected Result:

The size of "Review duplicates" and "More" buttons, should be the same when opening a report with more than one expense and when opening a report with a single expense.

Actual Result:

The size of "Review Duplicates" and "More" buttons, is different on a report with more than one expense and when opening a report with a single expense.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7113225_1774466735539.Size.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @mjasikowski (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[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.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #85530 - "Extract MoneyRequestHeaderActions to reduce re-renders" by @TMisiukiewicz (High confidence)
Related Issues: None

Recommendation: REVERT

PR #85530 refactored the MoneyRequestHeader component by extracting button actions into separate components. During this refactor, the flex styling logic for button sizing was changed in a way that causes inconsistent sizing behavior. The PR introduced a logic issue where the variable name isNarrow is semantically inverted from what it represents, and the flex growth styling is now applied differently than in the original implementation.

Labels: No label changes needed. This issue is correctly labeled as DeployBlockerCash since it is a frontend bug reproducible in staging but not in production, and caused by an App PR.

Details of Analysis

Evidence

• The bug is reproducible in staging (v9.3.47.0) but not in production
• PR Extract MoneyRequestHeaderActions to reduce re-renders #85530 is included in the current staging deploy (StagingDeployCash Deploy Checklist: New Expensify 2026-03-25 #86329)
• PR Extract MoneyRequestHeaderActions to reduce re-renders #85530 merged on 2026-03-25, which aligns with when this staging version was built
• The PR specifically refactored MoneyRequestHeader and the button rendering logic
• The bug specifically affects the "Review Duplicates" and "More" button sizing, which are the exact buttons this PR modified

Verification

I confirmed that PR #85530 modifies the following files that directly control the button rendering and sizing:

• src/components/MoneyRequestHeader.tsx (major refactor, 601 deletions)
• src/components/MoneyRequestHeaderActions.tsx (new file, wraps both buttons)
• src/components/MoneyRequestHeaderPrimaryAction.tsx (new file, "Review Duplicates" button)
• src/components/MoneyRequestHeaderSecondaryActions.tsx (new file, "More" button)

Root Cause

Original behavior (before PR #85530):

{!!primaryAction && <View style={[styles.flexGrow4]}>{primaryActionButton}</View>}
{!!applicableSecondaryActions.length && (
    <ButtonWithDropdownMenu
        wrapperStyle={[!primaryAction && styles.flexGrow4]}
        ...
    />
)}

• Primary action: Always gets flexGrow4 when it exists
• More button: Gets flexGrow4 ONLY when there is NO primary action

This ensured one button takes full width when alone, or both share space proportionally.

New behavior (after PR #85530):

In MoneyRequestHeaderPrimaryAction.tsx (line 168-172):

const isNarrow = !shouldUseNarrowLayout || (wideRHPRouteKeys.length > 0 && !isSmallScreenWidth);

if (isNarrow) {
    return button;  // No wrapper
}
return <View style={[styles.flexGrow4]}>{button}</View>;

In MoneyRequestHeaderSecondaryActions.tsx (line 502):

const isNarrow = !shouldUseNarrowLayout || (wideRHPRouteKeys.length > 0 && !isSmallScreenWidth);

wrapperStyle={!isNarrow ? [styles.flexGrow4] : undefined}

The issue is threefold:

1. Semantic inversion: The variable isNarrow is FALSE on mobile (narrow) devices because shouldUseNarrowLayout = true makes isNarrow = !true = false
2. Changed logic: Both buttons now get flexGrow4 based on the same isNarrow condition, rather than being mutually exclusive
3. Rendering context: The buttons may render in different contexts (report view vs expense detail view), causing the isNarrow calculation or component mounting to behave inconsistently

This results in the buttons having inconsistent sizes depending on the screen/context, as described in the bug report.