[$250] Expense - Duplicate expense created in the Expired Workspace

[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.32-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #83736
Email or phone of affected tester (no customers): luongquocvu92+010125@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 10/Chrome
App Component: Money Requests

Action Performed:

Preconditions: User has an Expired Workspace and is a member of another Workspace

1. Open the Workspace user as a member
2. Click on an expense has created
3. Click on the More button
4. Select Duplicate expense
5. Go to the Expired Workspace chat

Expected Result:

The duplicate expense should not be created in the Expired Workspace

Actual Result:

The duplicate expense displays in the Expired Workspace

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @eVoloshchak

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022043613175711864263
• Upwork Job ID: 2043613175711864263
• Last Price Increase: 2026-04-13

[MelvinBot]

Proposal

What is the root cause of that problem?

The duplicate expense flow never checks whether the target workspace has expired billing. When a user clicks "Duplicate expense," useDefaultExpensePolicy selects the target workspace using isPolicyAccessible, which only verifies the policy exists, isn't pending deletion, and the user has a role — it does not check billing/expiration status.

The function shouldRestrictUserBillableActions exists for exactly this purpose and is already used in the Add Expense handler (MoneyReportHeader.tsx:1778), but it is missing from the Duplicate Expense handler (MoneyReportHeader.tsx:1483-1521).

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

Add the same shouldRestrictUserBillableActions guard that exists in the Add Expense handler to the Duplicate Expense handler. Specifically, in MoneyReportHeader.tsx, inside the DUPLICATE_EXPENSE onSelected callback (around line 1483), add a check before proceeding with the duplication:

If the target policy (from defaultExpensePolicy) has restricted billable actions, navigate to ROUTES.RESTRICTED_ACTION and return early — exactly as the Add Expense handler does at line 1778.

The same fix should also be applied to the transaction-level duplicate action in MoneyRequestHeaderSecondaryActions.tsx which has the same gap.

Investigation details

Data flow (no expiration check at any step):

1. User clicks "Duplicate expense" → MoneyReportHeader.tsx:1478
2. isDuplicateAction() gate (ReportSecondaryActionUtils.ts:813-839) checks transaction count, scanning status, submitter — no expiration check
3. useDefaultExpensePolicy() selects target workspace via isPolicyAccessible() (PolicyUtils.ts:1787-1795) — only checks non-empty, has ID, not pending-delete, user has role
4. duplicateExpenseTransaction() (Duplicate.ts:665) creates expense in the target policy with no billing validation

Contrast with Add Expense (which works correctly):

• MoneyReportHeader.tsx:1778 calls shouldRestrictUserBillableActions(policy.id, ...) and navigates to the restricted action route if the workspace is expired

Both entry points affected:

• Report-level: MoneyReportHeader.tsx:1478-1521
• Transaction-level: MoneyRequestHeaderSecondaryActions.tsx:204-238

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

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