Member - Member role updated even if there was an error while updating

[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: v9.3.61-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #87994
Email or phone of affected tester (no customers): testpayment935@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 pro /Chrome
App Component: Workspace Settings

Action Performed:

1. Navigate to staging.new.expensify.com
2. Enable Simulate failing network requests.
3. Go to Workspace > Members.
4. Change a member's role.
5. Dismiss the error.
6. Disable Simulate failing network requests.

Expected Result:

After dismissing the error the member role should not updated once network is back

Actual Result:

Even if the request is fail in step 5, the role changed when network is back without changing it again.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7134925_1776778599538.bandicam_2026-04-21_16-35-45-608.mp4

View all open jobs on GitHub

[melvin-bot]

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

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

[MelvinBot]

Proposal

What is the root cause of that problem?

updateWorkspaceMembersRole uses API.write(), which persists the request to the SequentialQueue for automatic retry when the network recovers. When the request fails and the user dismisses the error, clearUpdateMemberRoleError only clears the pendingAction and errors fields in Onyx — it does not remove the persisted UpdateWorkspaceMembersRole request from the queue. So when the network comes back, the queue flushes and the server applies the role change that the user thought they dismissed.

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

In clearUpdateMemberRoleError (Member.ts:1157), after clearing the Onyx state, also remove the matching UpdateWorkspaceMembersRole request from PersistedRequests. This ensures that dismissing the error both reverts the UI and cancels the pending server-side update.

The removal should match on the command name (UpdateWorkspaceMembersRole) and the policyID parameter to target the correct request.

What alternative solutions did you explore? (Optional)

An alternative would be to switch from API.write to a non-persisted call, but that would break the offline-first pattern for this action and prevent legitimate retries when the user hasn't dismissed the error.

Investigation details

Data flow of the bug:

1. User changes member role while offline → updateWorkspaceMembersRole() calls API.write(), applying optimistic data and persisting the request
2. The request sits in the persisted queue waiting for network
3. On failure, failureData reverts the role in Onyx but the request remains in PersistedRequests
4. User dismisses the error → clearUpdateMemberRoleError() sets pendingAction: null and errors: null in Onyx, but the persisted request is untouched
5. Network comes back → the queue flushes → server applies the role change → successData overwrites the reverted role

Key code references:

• API.write call: Member.ts:718
• failureData (reverts role but keeps pendingAction): Member.ts:642-648
• clearUpdateMemberRoleError (incomplete — no PersistedRequests removal): Member.ts:1157-1166
• Dismiss handler in UI: WorkspaceMembersPage.tsx:380-382

Possibly related: #87709 — error not displayed in member row when changing role under simulated network failure (same PR #87994 area).

---

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.