[$250] Removed workspace member in offline mode is still visible in approval list

[nlemma]

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.51-7
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://github.com/Expensify/Expensify/issues/606731
Email or phone of affected tester (no customers): -
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11 Pro

Action Performed:

1. Launch the app

2. Create a new workspace
3. Invite a new member
4. Go offline
5. Select the newly invited member and remove from workspace
6. Open Workflows
7. Click “Add approval workflow” and observe the list approval member

Expected Result:

The member is removed when app offline shouldn't appear in the approval list

Actual Result:

The member is removed when app offline still appear in the approval list.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7104564_1773690966189.2026-03-16_21-48-17.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @parasharrajat

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022039720033496441954
• Upwork Job ID: 2039720033496441954
• Last Price Increase: 2026-04-09

[MelvinBot]

Proposal

What is the root cause of that problem?

When a workspace member is removed while offline, removeMembers() in Policy/Member.ts:381 sets pendingAction: 'delete' on the employee entry in policy.employeeList optimistically. The member is not actually removed from the list until the server confirms (at which point the entry is set to null). While offline, the success callback never fires, so the employee stays in employeeList with pendingAction: 'delete'.

The function convertPolicyEmployeesToApprovalWorkflows() in WorkflowUtils.ts iterates over all employees and builds two things:

1. availableMembers (line 138) — correctly filters out employees with pendingAction === DELETE
2. Per-workflow .members (line 167) — does NOT filter, unconditionally pushing every employee into the workflow's member list regardless of pendingAction

This inconsistency means removed-but-pending-delete members still appear in the "Expenses from" display of existing approval workflows on both the overview page and the edit page.

Additionally, the approver selection page WorkspaceWorkflowsApprovalsApproverPage.tsx:62-110 iterates over policy.employeeList directly without any pendingAction filtering, so removed members also appear as selectable approvers.

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

1. src/libs/WorkflowUtils.ts (line ~167) — Add a pendingAction !== DELETE guard before pushing a member into approvalWorkflows[submitsTo].members, matching the existing filter at line 138 for availableMembers. Members with pendingAction: 'delete' should be skipped when building per-workflow member lists.

2. src/pages/workspace/workflows/approvals/WorkspaceWorkflowsApprovalsApproverPage.tsx (line ~62-110) — Add a filter to exclude employees with pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE from the approver selection list, so that removed-while-offline members do not appear as selectable approvers.

What alternative solutions did you explore? (Optional)

An alternative would be to modify removeMembers() to fully remove the employee from employeeList optimistically (setting to null immediately instead of just marking pendingAction: 'delete'). However, this would conflict with the existing pattern where optimistic deletes use pendingAction to enable rollback on failure and to show red-brick-road indicators. The filtering approach is consistent with how availableMembers already works and is the minimal change.

---

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

[melvin-bot]

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

[KJ21-ENG]

Proposal

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

When a workspace member is removed while offline, that removed member can still appear in approval workflows (for example in approver selection and workflow member lists), even though they should no longer be eligible.

What is the root cause of that problem?

Offline member removal is optimistic and marks the member with pendingAction: DELETE instead of removing them immediately.

App/src/libs/actions/Policy/Member.ts

Lines 390 to 397 in 1d43910

	for (const email of selectedMemberEmailsWithDuplicates) {
	optimisticMembersState[email] = {pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE};
	successMembersState[email] = null;
	failureMembersState[email] = {
	pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
	errors: ErrorUtils.getMicroSecondOnyxErrorWithTranslationKey('workspace.people.error.genericRemove'),
	};
	}

Workflow conversion partially handles this: availableMembers excludes pendingAction === DELETE, but the same deleted member is still pushed into per-workflow members without the same guard.

App/src/libs/WorkflowUtils.ts

Lines 138 to 140 in 1d43910

	if (pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
	availableMembers.push(member);
	}

App/src/libs/WorkflowUtils.ts

Lines 167 to 173 in 1d43910

	approvalWorkflows[submitsTo].members.push(member);
	// Only propagate ADD/UPDATE pending actions to the workflow, not DELETE
	// When a member is being deleted from the workspace, their DELETE pending action
	// should not affect the workflow's display state (e.g., strikethrough styling)
	if (pendingAction && pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
	approvalWorkflows[submitsTo].pendingAction = pendingAction;
	}

Also, the approver selection page iterates over employeeList and does not filter out members with pendingAction: DELETE, so removed members remain selectable while offline.

App/src/pages/workspace/workflows/approvals/WorkspaceWorkflowsApprovalsApproverPage.tsx

Lines 57 to 75 in 1d43910

	return Object.values(employeeList)
	.map((employee): SelectionListApprover | null => {
	const email = employee.email;
	if (!email) {
	return null;
	}
	if (!isDefault && policy?.preventSelfApproval && membersEmail?.includes(email)) {
	return null;
	}
	// Do not allow the same email to be added twice
	const isEmailAlreadyInApprovers = approversFromWorkflow?.some((approver, index) => approver?.email === email && index !== approverIndex);
	if (isEmailAlreadyInApprovers && selectedApproverEmail !== email) {
	return null;
	}
	// Do not allow the default approver to be added as the first approver

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

1. In convertPolicyEmployeesToApprovalWorkflows() (WorkflowUtils.ts), skip adding members with pendingAction === DELETE to approvalWorkflows[submitsTo].members (same rule already used for availableMembers).
2. In WorkspaceWorkflowsApprovalsApproverPage.tsx, exclude employees with pendingAction === DELETE from the approver options list.
3. Keep optimistic delete behavior in removeMembers() unchanged (so rollback/error handling still works), but make workflow/approver UI consistently respect pending-delete members as hidden.
4. Add regression coverage for offline remove-member flow: remove member offline -> open workflow approvals -> verify removed member is absent from both “Expenses from” members and approver selector.

What alternative solutions did you explore? (Optional)

• Fully nulling employees immediately on optimistic remove was considered, but that is broader-risk and can interfere with rollback semantics.
• Consistent pending-delete filtering in workflow derivation + approver selection is a smaller and safer fix aligned with existing logic.

[ReaperOAK]

Proposal

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

When a workspace member is removed while the device is offline, they continue to appear in the approval workflow — both in the per-workflow "Expenses from" member list and in the approver selection list. The removed member should be visually absent from all approval-related lists until the device reconnects and the server confirms.

What is the root cause of that problem?

When removeMembers() in src/libs/actions/Policy/Member.ts executes offline, it sets pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE on the employee entry optimistically. The employee is only fully removed (set to null) on server confirmation, which never arrives while offline. This is correct behavior — the pendingAction pattern supports rollback on failure.

The bug is a partial implementation of the pendingAction: DELETE filter in convertPolicyEmployeesToApprovalWorkflows() (src/libs/WorkflowUtils.ts). The developer correctly handled three out of four cases:

1. availableMembers (line 138) — ✅ correctly filters: if (pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE)
2. workflowPendingAction (line 157) — ✅ correctly avoids propagating DELETE to the workflow's display state
3. Workflow pendingAction propagation (line 171) — ✅ correctly skips DELETE: if (pendingAction && pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE)
4. approvalWorkflows[submitsTo].members.push(member) (line 167) — ❌ unconditionally pushes every employee into the workflow's member list, including those with pendingAction: DELETE

This causes removed-but-pending-delete members to appear in the "Expenses from" display of every existing approval workflow (overview, edit page, and the "Expenses from" selection page for edit mode).

Additionally, WorkspaceWorkflowsApprovalsApproverPage.tsx (line ~62) iterates Object.values(employeeList) directly with zero pendingAction filtering, so removed-while-offline members also appear as selectable approvers. This page accesses employeeList raw rather than going through convertPolicyEmployeesToApprovalWorkflows.

Notably, the codebase already has the correct pattern elsewhere — WorkspaceWorkflowsPayerPage.tsx (line 92) specifically checks policyEmployee.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE to skip and disable pending-delete members in the payer selection list.

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

Fix 1: src/libs/WorkflowUtils.ts — Skip pending-delete members when building per-workflow member lists

At line ~167, add a pendingAction !== DELETE guard before pushing into approvalWorkflows[submitsTo].members, consistent with the existing guard at line 138:

-        approvalWorkflows[submitsTo].members.push(member);
+        if (pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
+            approvalWorkflows[submitsTo].members.push(member);
+        }

This single change cascades to fix all downstream consumers:

• WorkspaceWorkflowsPage.tsx — correct member count in workflow overview
• WorkspaceWorkflowsApprovalsEditPage.tsx — correct members in edit mode
• WorkspaceWorkflowsApprovalsExpensesFromPage.tsx — correct selected members via approvalWorkflow.members
• mergeWorkflowMembersWithAvailableMembers() — correct merged list (since workflow .members is now clean)

Fix 2: src/pages/workspace/workflows/approvals/WorkspaceWorkflowsApprovalsApproverPage.tsx — Filter pending-delete employees from approver selection

Inside the allApprovers useMemo (line ~62), add an early return for pending-delete employees when mapping Object.values(employeeList):

         return Object.values(employeeList)
             .map((employee): SelectionListApprover | null => {
                 const email = employee.email;

                 if (!email) {
                     return null;
                 }

+                if (employee.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
+                    return null;
+                }
+
                 if (!isDefault && policy?.preventSelfApproval && membersEmail?.includes(email) && visibleSelectedApproverEmail !== email) {

This aligns with the existing WorkspaceWorkflowsPayerPage.tsx pattern for filtering pending-delete employees from selection lists.

What alternative solutions did you explore? (Optional)

An alternative is to modify removeMembers() in Policy/Member.ts to fully remove the employee from employeeList optimistically (set to null immediately) rather than setting pendingAction: 'delete'. This would fix all downstream consumers without touching any UI code. However, this breaks the established pendingAction pattern used across the entire codebase for optimistic deletes — it enables rollback on failure and powers red-brick-road indicators for error states. Removing the employee entry entirely would make rollback on reconnection failure impossible.

The filtering approach is superior because:

1. It is consistent with how availableMembers already works at line 138 of the same function (same developer, same file, same loop — just a missed guard)
2. It matches the existing pattern in WorkspaceWorkflowsPayerPage.tsx for handling pending-delete in selection lists
3. It preserves the pendingAction rollback mechanism
4. It is the minimal, surgical change with zero regression risk

[wildan-m]

Proposal

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

After removing a workspace member while offline, that member remains visible in three separate approval workflow screens — the workflow member display, the approver picker, and the over-limit approver picker.

What is the root cause of that problem?

Calling removeMembers() offline marks the employee with pendingAction: 'delete' but does not remove them from policy.employeeList until the server confirms. Three independent UI code paths fail to exclude these pending-delete entries:

Path 1 — Per-workflow member aggregation in convertPolicyEmployeesToApprovalWorkflows(). The function already filters availableMembers correctly at line 138, but the loop that populates each workflow's .members array at line 167 has no equivalent guard — every employee is pushed regardless of pendingAction:

App/src/libs/WorkflowUtils.ts

Lines 130 to 174 in 0bf4707

	for (const employee of Object.values(employees)) {
	const {email, submitsTo, pendingAction} = employee;
	if (!email) {
	continue;
	}
	const member = buildMemberFromEmployee(employee, personalDetailsByEmail, email);
	if (pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
	availableMembers.push(member);
	}
	if (!submitsTo || !employees[submitsTo]) {
	continue;
	}
	if (!approvalWorkflows[submitsTo]) {
	const approvers = calculateApprovers({employees, firstEmail: submitsTo, personalDetailsByEmail});
	if (submitsTo !== firstApprover) {
	for (const approver of approvers) {
	usedApproverEmails.add(approver.email);
	}
	}
	// Only set ADD/UPDATE pending actions on the workflow, not DELETE
	// When a member is being deleted from the workspace, their DELETE pending action
	// should not affect the workflow's display state
	const workflowPendingAction = pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE ? pendingAction : undefined;
	approvalWorkflows[submitsTo] = {
	members: [],
	approvers,
	isDefault: defaultApprover === submitsTo,
	pendingAction: workflowPendingAction,
	};
	}
	approvalWorkflows[submitsTo].members.push(member);
	// Only propagate ADD/UPDATE pending actions to the workflow, not DELETE
	// When a member is being deleted from the workspace, their DELETE pending action
	// should not affect the workflow's display state (e.g., strikethrough styling)
	if (pendingAction && pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
	approvalWorkflows[submitsTo].pendingAction = pendingAction;
	}
	}

Path 2 — Approver selection list in WorkspaceWorkflowsApprovalsApproverPage. The allApprovers memo maps over Object.values(employeeList) without checking pendingAction, so a deleted member appears as a selectable approver:

App/src/pages/workspace/workflows/approvals/WorkspaceWorkflowsApprovalsApproverPage.tsx

Lines 62 to 110 in 0bf4707

	return Object.values(employeeList)
	.map((employee): SelectionListApprover | null => {
	const email = employee.email;
	if (!email) {
	return null;
	}
	if (!isDefault && policy?.preventSelfApproval && membersEmail?.includes(email) && visibleSelectedApproverEmail !== email) {
	return null;
	}
	// Do not allow the same email to be added twice
	const isEmailAlreadyInApprovers = approversFromWorkflow?.some((approver, index) => approver?.email === email && index !== approverIndex);
	if (isEmailAlreadyInApprovers && visibleSelectedApproverEmail !== email) {
	return null;
	}
	// Do not allow the default approver to be added as the first approver
	if (!isDefault && approverIndex === 0 && defaultApprover === email) {
	return null;
	}
	const policyMemberEmailsToAccountIDs = getMemberAccountIDsForWorkspace(employeeList);
	const accountID = Number(policyMemberEmailsToAccountIDs[email] ?? '');
	if (!accountID) {
	return null;
	}
	const {avatar, displayName = email, login} = personalDetails?.[accountID] ?? {};
	return {
	text: displayName,
	alternateText: email,
	keyForList: email,
	isSelected: visibleSelectedApproverEmail === email,
	login: email,
	icons: [{source: avatar ?? icons.FallbackAvatar, type: CONST.ICON_TYPE_AVATAR, name: displayName, id: accountID}],
	rightElement: (
	<MemberRightIcon
	role={employee.role}
	owner={policy?.owner}
	login={login}
	/>
	),
	};
	})
	.filter((approver): approver is SelectionListApprover => !!approver);

Path 3 — Over-limit approver selection list in WorkspaceWorkflowsApprovalsOverLimitApproverPage. This page has identical unfiltered iteration over employeeList — a deleted member can be selected as the escalation approver for reports exceeding an approval limit:

App/src/pages/workspace/workflows/approvals/WorkspaceWorkflowsApprovalsOverLimitApproverPage.tsx

Lines 53 to 93 in 0bf4707

	return Object.values(employeeList)
	.map((employee): SelectionListApprover | null => {
	const email = employee.email;
	if (!email) {
	return null;
	}
	if (!isDefault && policy?.preventSelfApproval && membersEmail?.includes(email)) {
	return null;
	}
	if (email === currentApproverEmail) {
	return null;
	}
	const accountID = Number(policyMemberEmailsToAccountIDs[email] ?? '');
	if (!accountID) {
	return null;
	}
	const {avatar, displayName = email, login} = personalDetails?.[accountID] ?? {};
	return {
	text: displayName,
	alternateText: email,
	keyForList: email,
	isSelected: currentApprover?.overLimitForwardsTo === email,
	login: email,
	icons: [{source: avatar ?? expensifyIcons.FallbackAvatar, type: CONST.ICON_TYPE_AVATAR, name: displayName, id: accountID}],
	rightElement: (
	<MemberRightIcon
	role={employee.role}
	owner={policy?.owner}
	login={login}
	/>
	),
	};
	})
	.filter((approver): approver is SelectionListApprover => !!approver);
	})();

All three paths need the same fix: skip entries where pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE.

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

1. src/libs/WorkflowUtils.ts — Guard the .members.push(member) call at line 167 with if (pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE), consistent with the existing availableMembers filter at line 138.

2. src/pages/workspace/workflows/approvals/WorkspaceWorkflowsApprovalsApproverPage.tsx — Inside the .map() callback, return null early when employee.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE.

3. src/pages/workspace/workflows/approvals/WorkspaceWorkflowsApprovalsOverLimitApproverPage.tsx — Same early-return filter inside its .map() callback to exclude pending-delete employees from the over-limit approver picker.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/86971-offline-removed-member-approval-list?expand=1

What alternative solutions did you explore? (Optional)

Removing the employee from employeeList immediately during optimistic delete (setting to null instead of marking pendingAction: 'delete') would solve all three paths at once. However, this breaks the established rollback pattern — on network failure, the member needs to be restored with an error indicator, which requires the original entry to still exist in the list. Filtering at each consumption point preserves rollback semantics and matches the pattern already used for availableMembers.

[github-actions]

⚠️ @wildan-m Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[trasnake87]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.