[Due for payment 2026-06-16] [$250] Pending deleted report field data is counted in confirmation page of duplicate WS

[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.67-3
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #87737
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 / Chrome, Samsung Galaxy A52 / Android 14, iPhone 13 / iOS 26.5
App Component: Workspace Settings

Action Performed:

Preconditions

• Logged in to any user
• Create a workspace with distance rates, merchant rules, taxes, categories, members, report fields data

Steps:

1. Go offline
2. Delete a rule, a member, a tax, a category, a distance rate, a report field
3. Duplicate the workspace
4. Observe the pending deleted data confirmation page -> note that here the report field is counted as 1
5. Tap "continue"
6. Tap the duplicate workspace
7. Open "Reports" in the workspace setting

Expected Result:

In step 4, the pending deleted report field data shouldn't be counted. It should match what appears when opening the report in the duplicated workspace, where there are no report fields.

Actual Result:

in step 4, the pending deleted report field data is counted in confirmation page of duplicate WS

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022051994541233752335
• Upwork Job ID: 2051994541233752335
• Last Price Increase: 2026-05-06

Issue Owner

Current Issue Owner: @sobitneupane

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #87737

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

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #87737 - "fix: Offline deleted rules reappear after reconnecting until cache is cleared v2" by @nkdengineer (High confidence)
Related Issues: #83130

Recommendation: REVERT

PR #87737 was intended to fix offline-deleted items reappearing and to exclude pending-delete items from the workspace duplication confirmation page count, but the fix is incomplete for report fields — pending-deleted report fields are still counted. The PR is in the current staging release and should be reverted so the incomplete fix does not ship.

Assigned: @nkdengineer (PR author), @JS00001 (approving reviewer), @sobitneupane (approving reviewer) from highest-confidence causing PR only
Labels: No label changes made — DeployBlockerCash is correct (this is a Frontend/App bug requiring a fix in Expensify/App). No DeployBlocker label is present.

Detailed Analysis

Evidence

• The issue was caught during QA regression testing explicitly for PR fix: Offline deleted rules reappear after reconnecting until cache is cleared v2 #87737 (BrowserStack link in the issue body points to https://github.com/Expensify/App/pull/87737).
• melvin-bot automatically assigned the PR author because of this PR's merge.
• PR fix: Offline deleted rules reappear after reconnecting until cache is cleared v2 #87737 merged on 2026-05-05, and the issue was filed on 2026-05-06 during staging QA of v9.3.67-3.
• The PR modifies WorkspaceDuplicateSelectFeaturesForm.tsx (the confirmation page) specifically to fix the count of pending-deleted items, but the report fields case remains broken.
• The bug is reproducible in both staging and production, suggesting the underlying issue pre-existed, but PR fix: Offline deleted rules reappear after reconnecting until cache is cleared v2 #87737 was the fix attempt that QA was validating — and it failed QA for the report fields case.

Verification

• The affected file is src/pages/workspace/duplicate/WorkspaceDuplicateSelectFeaturesForm.tsx, which is directly modified by PR fix: Offline deleted rules reappear after reconnecting until cache is cleared v2 #87737.
• PR fix: Offline deleted rules reappear after reconnecting until cache is cleared v2 #87737 also modifies src/libs/ReportUtils.ts (changes the return type of getReportFieldsByPolicyID from Record<string, PolicyReportField> to Policy['fieldList']) and src/libs/actions/Policy/Policy.ts (adds buildOptimisticDuplicatePolicy with filterPendingDeleteData for fieldList).

Root Cause

In WorkspaceDuplicateSelectFeaturesForm.tsx line 49, the PR attempts to filter out pending-deleted report fields:

const reportFields =
  Object.values(getReportFieldsByPolicyID(policyID) ?? {}).filter(
    (field) =>
      field.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
  ).length ?? 0;

For other item types (taxes, categories, coding rules, tags, distance rates), the filter works correctly because those data structures are read from Onyx collections where pendingAction is populated. However, getReportFieldsByPolicyID reads policy.fieldList from the in-memory Onyx policy cache. The fieldList items are of type OnyxValueWithOfflineFeedback<PolicyReportField>, which should include pendingAction, but when a report field is deleted offline, the pendingAction on the fieldList entry may not be set to DELETE at the point where this count is computed — meaning the filter condition is ineffective and the pending-deleted report field is still counted. The fix in buildOptimisticDuplicatePolicy correctly uses filterPendingDeleteData for the actual duplication, but the count shown in the confirmation page UI still does not reflect the correct number.