[$250] Full story : Migrate customer receives multiple unclear RBR errors when removing workspace members before cancelling account

[m-natarajan]

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:
Reproducible in staging?: Needs Reproduction (Reproduction blocked)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @JmillsExpensify
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. A migrate customer attempts to cancel their account.
2. The user follows the Concierge message instructions to remove all workspace members first.
3. The user proceeds to remove workspace members.
4. While doing so, the system displays a full page of RBR (Request Blocked by Rules) errors.

Expected Result:

The system should display clear and actionable error messages explaining what requirement is blocking the action.

Actual Result:

The user receives multiple RBR errors on the page. (There was a problem removing that workspace member)
Only one of the messages clearly explains the issue, while the others are unclear and not actionable.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

The link for the fullstory is in Slack thread

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @Pujan92

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022029689057376817764
• Upwork Job ID: 2029689057376817764
• Last Price Increase: 2026-04-02

[MelvinBot]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[melvin-bot]

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

[MelvinBot]

Proposal

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

When a migrate customer attempts to remove workspace members (as part of cancelling their account), the system displays a full page of RBR (Red Brick Road) errors with the generic message "There was a problem removing that workspace member" on many/all member rows — not just the members the user selected for removal.

What is the root cause of that problem?

The root cause is a bug in the removeMembers() function in src/libs/actions/Policy/Member.ts at lines 380-388. The code intends to handle duplicate logins (secondary logins) for the selected members being removed, but it incorrectly iterates over all employees in the policy and adds any employee without cached personal details to the deletion batch — not just secondary logins of the selected members.

const selectedMemberEmailsWithDuplicates: string[] = [...selectedMemberEmails];
for (const employeeEmail of Object.keys(policy?.employeeList ?? {})) {
    const personalDetails = getPersonalDetailByEmail(employeeEmail);
    if (personalDetails) {
        continue;
    }
    selectedMemberEmailsWithDuplicates.push(employeeEmail);
}

The assumption that "no personal details = secondary login" is flawed. For migrate customers, many employees may not have cached personal details (e.g., they were imported from old Expensify and their personal details haven't been fetched yet). This causes selectedMemberEmailsWithDuplicates to balloon with unrelated employees.

When the API call fails, the failure data sets pendingAction: DELETE and the generic error on every email in this inflated list (lines 390-397). Since isDeletedPolicyEmployee() in PolicyUtils.ts:1629 returns false for members with both pendingAction: DELETE and non-empty errors, those members reappear in the list with visible RBR error messages. This propagates red indicators up through the workspace initial page, workspaces list, and even the navigation tab bar.

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

The fix should be in src/libs/actions/Policy/Member.ts in the removeMembers() function. The duplicate-login loop at lines 381-388 needs to be scoped to only find secondary logins that actually correspond to the selected members, rather than adding all employees without personal details.

One approach: instead of checking personal details cache (which is unreliable for determining secondary logins), compare account IDs. For each employee in the policy without personal details, check if there's a selected member email that maps to the same account ID via policyMemberEmailsToAccountIDs. Only add the employee to the batch if its account ID matches one of the selected members' account IDs.

What alternative solutions did you explore? (Optional)

An alternative would be to remove the duplicate-login handling entirely and rely on the backend to handle secondary login cleanup. However, this could leave stale secondary login entries in Onyx. The scoped approach is safer as it preserves the original intent while fixing the over-selection bug.

---

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 - @Pujan92 (External)

[melvin-bot]

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

[wolram]

Proposal

---

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

When a migrate customer removes workspace members, the system floods the page with the generic RBR error, "There was a problem removing that workspace member," on members the user never selected for removal.

---

What is the root cause of that problem?

In removeMembers() (src/libs/actions/Policy/Member.ts), the code tries to include secondary logins by using “missing cached personal details” as a proxy for “secondary login.”

That assumption is incorrect for migrate customers. Many workspace members imported from Old Expensify do not have cached personal details yet, even though they are unrelated to the selected members. As a result, they get incorrectly appended to selectedMemberEmailsWithDuplicates.

Once that inflated batch is sent through the failure path, the code assigns pendingAction: DELETE and the generic RBR error to every email in the list. Those members then reappear in the UI with visible errors, which propagates red indicators through the workspace flow, the workspaces list, and the navigation tab bar.

---

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

We should replace the personal-details heuristic in removeMembers() with positive accountID matching, so we only include true same-account secondary logins.

Specifically:

• Build a Set of selected members’ accountIDs from selectedMemberEmails using policyMemberEmailsToAccountIDs
• When iterating over policy.employeeList, only append an additional email if:
  • it is not already selected, and
  • its resolved accountID matches one of the selected members’ accountIDs
• Resolve the candidate accountID with:
  • policyMemberEmailsToAccountIDs[email] ?? getPersonalDetailByEmail(email)?.accountID
• Skip candidates whose accountID is missing or does not match the selected set
• Deduplicate the final list before applying optimistic/failure updates

This keeps the existing secondary-login cleanup behavior, but narrows it to confirmed same-account entries instead of unrelated members with missing cached details.

No API or interface changes are required, and no behavioral changes are needed in downstream optimistic/failure handling — only the input list feeding those updates should change.

Tests (tests/actions/PolicyMemberTest.ts):

• Create a policy with:
  • A: selected member with known accountID
  • B: true secondary login sharing A’s accountID but with no cached personal details
  • C: unrelated member with no cached personal details and no matching accountID
• Call removeMembers() with mockFetch.fail
• Assert that only A and B receive pendingAction: DELETE and the generic error
• Assert that C remains untouched
• Add coverage confirming that a true secondary login is still included when it shares the same accountID, so the original cleanup intent is preserved

---

What alternative solutions did you explore?

I considered removing the duplicate-login expansion entirely and relying on the backend, but rejected that approach because it could leave stale secondary-login entries in Onyx on the client side.