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

@sobitneupane

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:

Go offline
Delete a rule, a member, a tax, a category, a distance rate, a report field
Duplicate the workspace
Observe the pending deleted data confirmation page -> note that here the report field is counted as 1
Tap "continue"
Tap the duplicate workspace
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:

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

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

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

👋 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:

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

@nkdengineer

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.

@sobitneupane

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

Exclude built-in title field from duplicate workspace report fields count #90340

If no regressions arise, payment will be issued on 2026-06-16. 🎊

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

@sobitneupane requires payment through NewDot Manual Requests

@sobitneupane

@sobitneupane 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]. If no checklist is needed for this issue, you can click: [no checklist button]

@sobitneupane

@sobitneupane Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

@mallenexpensify

Triggered auto assignment to @mallenexpensify (Awaiting Payment)

@sobitneupane

Payment Summary

Upwork Job

Reviewer: @sobitneupane owed $250 via NewDot

BugZero Checklist (@mallenexpensify)

I have verified the correct assignees and roles are listed above and updated the necessary manual offers
I have verified that there are no duplicate or incorrect contracts on Upwork for this job (https://www.upwork.com/ab/applicants/2051994541233752335/hired)
I have verified the PR was not reverted
I have applied any discounts due to bugs/regressions introduced by this PR
I have paid out the Upwork contracts or cancelled the ones that are incorrect
I have verified the payment summary above is correct

BugZero Checklist:

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

Link to the comment on the PR: Duplicate workspace #69146 (comment)
Link to the comment on the Issue: [Due for payment 2025-09-19] [Due for payment 2025-09-04] Implement Duplicate Workspace feature #67289 (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: N/A
[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.
[BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.

Link to issue: https://github.com/Expensify/Expensify/issues/649797

Regression Test Proposal

Test:

Disable Report fields in a workspace (Workspace > Reports).
Duplicate the workspace.
Verify that Report fields is disabled in the duplicated workspace.
Enable Report fields in the workspace (Workspace > Reports).
Duplicate the workspace.
Verify that Report fields is enabled in the duplicated workspace.

Do we agree 👍 or 👎

Zapier Logs

Run ID: 00040eee-25c5-ab5e-e4c7-d6fecc2fab04

@sobitneupane

@sobitneupane from the C+ doc

If there are posts on the PR or issue that reference a regression or deploy blocker, C+ posts on the issue and confirms regression (which will reduce pay by 50%) or provides reasoning why they shouldn’t be considered. If the C+ doesn’t update the issue, the contributor manager making the payment will assume any mention of a regression or deploy blockers reduces the issue amount.

It appears you reviewed the PR responsible for this regression. If so, you wouldn't be due payment, correct?

Causing PR: #87737 -

@mallenexpensify

@mallenexpensify The issue was already reproducible in production (#89716 (comment)). This is not a regression.

@sobitneupane

Payment Summary

Contributor+: @sobitneupane due $250 via NewDot

Thx Sobit, please post about deploy blockers/regressions around the time payment is due, I can't read all comments on all issues I pay to determine if the amount should be reduced. Thx

@sobitneupane

$250 approved for @sobitneupane

Navigation Menu

Repository navigation

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

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Investigation Summary

Recommendation: REVERT

Evidence

Verification

Root Cause

61 remaining items

Payment Summary

BugZero Checklist (@mallenexpensify)

BugZero Checklist:

Regression Test Proposal

Test:

Payment Summary

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Activity

melvin-bot commented on May 6, 2026

melvin-bot commented on May 6, 2026

github-actions commented on May 6, 2026

OSBotify commented on May 6, 2026

Investigation Summary

Recommendation: REVERT

Evidence

Verification

Root Cause

61 remaining items

melvin-bot commented on Jun 9, 2026

melvin-bot commented on Jun 9, 2026

melvin-bot commented on Jun 12, 2026

melvin-bot commented on Jun 15, 2026

melvin-bot commented on Jun 15, 2026

Payment Summary

BugZero Checklist (@mallenexpensify)

sobitneupane commented on Jun 16, 2026

BugZero Checklist:

Regression Test Proposal

Test:

mallenexpensify commented on Jun 17, 2026

sobitneupane commented on Jun 18, 2026

mallenexpensify commented on Jun 18, 2026

Payment Summary

JmillsExpensify commented on Jul 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions