[$125] Workspace - Approver user briefly reappears in member list after removal

[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.5-0
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://test-management.browserstack.com/projects/2219752/folder/13177080/test-cases/41237948
Email or phone of affected tester (no customers): lattelover1412+2101.b@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: android
App Component: Workspace Settings

Action Performed:

Precondition: user is admin and has at least one workspace which enable workflow and approvals

1. Launch the app
2. User logged in
3. Navigate to workspace >> Members >> Invited a user to the workspace
4. Navigate to workflow and Add the recently added member as the approver
5. Navigate to Members>> Tap on the member that is the approver to open user profile page
6. Tap "remove from workspace" >> Tap "Remove"

Expected Result:

• Once removed, the approver should disappear immediately from the member list without being briefly highlighted

Actual Result:

• After removal, the approver is briefly shown highlighted in the member list before disappearing.
• This flicker/glitch does not occur when removing a non-approver user, please refer to the attachment non_approval_user.mp4

Note: the issue is not occurred on Web, and IOS build is not updated

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7054267_1768936860500.Recording__3212.mp4

Bug7054267_1768937314280.non-approval_user.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022014043035613046742
• Upwork Job ID: 2014043035613046742
• Last Price Increase: 2026-01-28

[melvin-bot]

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

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-02-01 19:38:15 UTC.

Proposal

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

When removing a workspace member who is set as an approver, they briefly reappear highlighted in the member list before disappearing. This flicker does not occur when removing a non-approver user.

What is the root cause of that problem?

When a member who is an approver is removed, two API calls are dispatched back to back:

1. updateApprovalWorkflow (or removeApprovalWorkflow) dispatches first, setting pendingAction: UPDATE on the removed member in its optimistic data
2. removeMembers dispatches second, setting pendingAction: DELETE

The DELETE overrides UPDATE via Onyx merge so the member disappears. But when the server responds to UPDATE_WORKSPACE_APPROVAL, the successData blindly clears pendingAction to null for all employees it touched, including the removed member. This undoes the DELETE state and the member briefly reappears until the DELETE_MEMBERS_FROM_WORKSPACE response arrives.

The successData that causes this:

App/src/libs/actions/Workflow.ts

Line 154 in 9618ba6

employeeList: Object.fromEntries(Object.keys(updatedEmployees).map((key) => [key, {pendingAction: null, pendingFields: null}])),

There is preservation logic that keeps DELETE if already set, but it can't help here because previousEmployeeList hardcodes pendingAction to null when it's built:

App/src/libs/actions/Workflow.ts

Line 106 in 9618ba6

const previousEmployeeList = Object.fromEntries(Object.entries(policy.employeeList ?? {}).map(([key, value]) => [key, {...value, pendingAction: null}]));

App/src/libs/WorkflowUtils.ts

Line 292 in 9618ba6

pendingAction: previousPendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE ? previousPendingAction : pendingAction,

Just reordering the calls doesn't fix it either because policy is passed as a parameter from React state, which is stale (hasn't re-rendered), so the preservation logic can't detect the DELETE regardless of call order.

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

Two changes:

1. Reorder operations in removeUser: Call removeMemberAndCloseModal() first so the member disappears immediately via pendingAction: DELETE.

App/src/pages/workspace/members/WorkspaceMemberDetailsPage.tsx

Lines 193 to 221 in 9618ba6

	const removeUser = () => {
	const ownerEmail = ownerDetails?.login;
	const removedApprover = personalDetails?.[accountID];
	// If the user is not an approver, proceed with member removal
	if (!isApproverUserAction(policy, memberLogin) || !removedApprover?.login || !ownerEmail) {
	removeMemberAndCloseModal();
	return;
	}
	// Update approval workflows after approver removal
	const updatedWorkflows = updateWorkflowDataOnApproverRemoval({
	approvalWorkflows,
	removedApprover,
	ownerDetails,
	});
	for (const workflow of updatedWorkflows) {
	if (workflow?.removeApprovalWorkflow) {
	const {removeApprovalWorkflow, ...updatedWorkflow} = workflow;
	removeApprovalWorkflowAction(updatedWorkflow, policy);
	} else {
	updateApprovalWorkflow(workflow, [], [], policy);
	}
	}
	// Remove the member and close the modal
	removeMemberAndCloseModal();

2. Exclude the removed member from the workflow update's employee data in updateApprovalWorkflow and removeApprovalWorkflow: Accept an optional list of emails to exclude from updatedEmployees before dispatching. Since the member is being deleted from the workspace, there's no need to include them in the workflow's optimistic/success/failure data. This completely prevents the workflow's successData from ever touching the deleted member's entry.

App/src/libs/actions/Workflow.ts

Line 99 in 9618ba6

function updateApprovalWorkflow(approvalWorkflow: ApprovalWorkflow, membersToRemove: Member[], approversToRemove: Approver[], policy: OnyxEntry<Policy>) {

App/src/libs/actions/Workflow.ts

Line 167 in 9618ba6

function removeApprovalWorkflow(approvalWorkflow: ApprovalWorkflow, policy: OnyxEntry<Policy>) {

In WorkspaceMemberDetailsPage.tsx, the updated flow would be:

• Call removeMemberAndCloseModal() first
• Then call updateApprovalWorkflow(workflow, [], [], policy, [memberLogin]) or removeApprovalWorkflowAction(updatedWorkflow, policy, [memberLogin]), passing the removed email so it gets filtered out

In Workflow.ts, both updateApprovalWorkflow and removeApprovalWorkflow would take an optional excludeFromUpdates parameter and filter those emails out of updatedEmployees after it's computed by convertApprovalWorkflowToPolicyEmployees.

The same pattern should be applied to removeUsers in WorkspaceMembersPage.tsx for bulk member removal:

App/src/pages/workspace/WorkspaceMembersPage.tsx

Line 237 in 9618ba6

const removeUsers = () => {

What alternative solutions did you explore? (Optional)

N/A

[annaweber830]

Proposal

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

When removing a workspace member who is also an approver, the member briefly reappears (highlighted) in the workspace members list before disappearing. This flicker does not happen when removing a non-approver.

What is the root cause of that problem?

Removing an approver triggers two sets of optimistic updates:

• The workspace member removal sets the member’s employeeList entry to pendingAction: DELETE (so they should be filtered out immediately).
• In parallel, the approval workflow update/removal writes to policy.employeeList and then its success Onyx updates clear pendingAction for affected employees. If those workflow updates touch the same removed user, the DELETE pendingAction gets cleared momentarily, causing the UI to render the member again until the delete call finishes.

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

Preserve pendingAction: DELETE in workflow-related success Onyx updates so they don’t undo a concurrent member removal state.
Reorder the removal flow so we set the member removal state first (immediate disappearance), then perform any approval workflow updates that are required when an approver is removed.

App/src/libs/actions/Workflow.ts

Line 42 in e54cfd4

const previousEmployeeList = Object.fromEntries(Object.entries(policy.employeeList ?? {}).map(([key, value]) => [key, {...value, pendingAction: null}]));

const previousEmployeeList = Object.fromEntries(Object.entries(policy.employeeList ?? {}).map(([key, value]) => [key, {...value}]));

App/src/libs/actions/Workflow.ts

Lines 78 to 86 in e54cfd4

	const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.POLICY>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.POLICY}${policy.id}`,
	value: {
	employeeList: Object.fromEntries(Object.keys(updatedEmployees).map((key) => [key, {pendingAction: null, pendingFields: null}])),
	},
	},
	];

const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.POLICY>> = [
        {
            onyxMethod: Onyx.METHOD.MERGE,
            key: `${ONYXKEYS.COLLECTION.POLICY}${policy.id}`,
            value: {
                employeeList: Object.fromEntries(
                    Object.keys(updatedEmployees).map((key) => [
                        key,
                        previousEmployeeList[key]?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE ? {pendingFields: null} : {pendingAction: null, pendingFields: null},
                    ]),
                ),
            },
        },
    ];

App/src/libs/actions/Workflow.ts

Line 106 in e54cfd4

const previousEmployeeList = Object.fromEntries(Object.entries(policy.employeeList ?? {}).map(([key, value]) => [key, {...value, pendingAction: null}]));

const previousEmployeeList = Object.fromEntries(Object.entries(policy.employeeList ?? {}).map(([key, value]) => [key, {...value}]));

App/src/libs/actions/Workflow.ts

Lines 149 to 157 in e54cfd4

	const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.POLICY>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.POLICY}${policy.id}`,
	value: {
	employeeList: Object.fromEntries(Object.keys(updatedEmployees).map((key) => [key, {pendingAction: null, pendingFields: null}])),
	},
	},
	];

const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.POLICY>> = [
       {
           onyxMethod: Onyx.METHOD.MERGE,
           key: `${ONYXKEYS.COLLECTION.POLICY}${policy.id}`,
           value: {
               employeeList: Object.fromEntries(
                   Object.keys(updatedEmployees).map((key) => [
                       key,
                       previousEmployeeList[key]?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE ? {pendingFields: null} : {pendingAction: null, pendingFields: null},
                   ]),
               ),
           },
       },
   ];

App/src/libs/actions/Workflow.ts

Line 172 in e54cfd4

const previousEmployeeList = Object.fromEntries(Object.entries(policy.employeeList ?? {}).map(([key, value]) => [key, {...value, pendingAction: null}]));

const previousEmployeeList = Object.fromEntries(Object.entries(policy.employeeList ?? {}).map(([key, value]) => [key, {...value}]));

App/src/libs/actions/Workflow.ts

Lines 207 to 215 in e54cfd4

	const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.POLICY>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.POLICY}${policy.id}`,
	value: {
	employeeList: Object.fromEntries(Object.keys(updatedEmployees).map((key) => [key, {pendingAction: null}])),
	},
	},
	];

const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.POLICY>> = [
        {
            onyxMethod: Onyx.METHOD.MERGE,
            key: `${ONYXKEYS.COLLECTION.POLICY}${policy.id}`,
            value: {
                employeeList: Object.fromEntries(
                    Object.keys(updatedEmployees).map((key) => [
                        key,
                        previousEmployeeList[key]?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE ? {pendingFields: null} : {pendingAction: null, pendingFields: null},
                    ]),
                ),
            },
        },
    ];

App/src/pages/workspace/WorkspaceMembersPage.tsx

Lines 237 to 276 in e54cfd4

	const removeUsers = () => {
	// Check if any of the members are approvers
	const hasApprovers = selectedEmployees.some((email) => isApprover(policy, email));
	if (hasApprovers) {
	const ownerEmail = ownerDetails.login;
	for (const login of selectedEmployees) {
	if (!isApprover(policy, login)) {
	continue;
	}
	const accountID = policyMemberEmailsToAccountIDs[login];
	const removedApprover = personalDetails?.[accountID];
	if (!removedApprover?.login || !ownerEmail) {
	continue;
	}
	const updatedWorkflows = updateWorkflowDataOnApproverRemoval({
	approvalWorkflows,
	removedApprover,
	ownerDetails,
	});
	for (const workflow of updatedWorkflows) {
	if (workflow?.removeApprovalWorkflow) {
	const {removeApprovalWorkflow, ...updatedWorkflow} = workflow;
	removeApprovalWorkflowAction(updatedWorkflow, policy);
	} else {
	updateApprovalWorkflow(workflow, [], [], policy);
	}
	}
	}
	}
	setRemoveMembersConfirmModalVisible(false);
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	InteractionManager.runAfterInteractions(() => {
	setSelectedEmployees([]);
	removeMembers(policyID, selectedEmployees, policyMemberEmailsToAccountIDs);
	});
	};

const removeUsers = () => {
        const selectedEmployeesToRemove = [...selectedEmployees];

        setRemoveMembersConfirmModalVisible(false);

        // eslint-disable-next-line @typescript-eslint/no-deprecated
        InteractionManager.runAfterInteractions(() => {
            setSelectedEmployees([]);
            removeMembers(policyID, selectedEmployeesToRemove, policyMemberEmailsToAccountIDs);
        });

        // Check if any of the members are approvers
        const hasApprovers = selectedEmployeesToRemove.some((email) => isApprover(policy, email));

        if (hasApprovers) {
            const ownerEmail = ownerDetails.login;
            for (const login of selectedEmployeesToRemove) {
                if (!isApprover(policy, login)) {
                    continue;
                }

                const accountID = policyMemberEmailsToAccountIDs[login];
                const removedApprover = personalDetails?.[accountID];
                if (!removedApprover?.login || !ownerEmail) {
                    continue;
                }
                const updatedWorkflows = updateWorkflowDataOnApproverRemoval({
                    approvalWorkflows,
                    removedApprover,
                    ownerDetails,
                });
                for (const workflow of updatedWorkflows) {
                    if (workflow?.removeApprovalWorkflow) {
                        const {removeApprovalWorkflow, ...updatedWorkflow} = workflow;
                        removeApprovalWorkflowAction(updatedWorkflow, policy);
                    } else {
                        updateApprovalWorkflow(workflow, [], [], policy);
                    }
                }
            }
        }
    };

App/src/pages/workspace/members/WorkspaceMemberDetailsPage.tsx

Lines 212 to 241 in e54cfd4

	const removeUser = useCallback(() => {
	const ownerEmail = ownerDetails?.login;
	const removedApprover = personalDetails?.[accountID];
	// If the user is not an approver, proceed with member removal
	if (!isApproverUserAction(policy, memberLogin) || !removedApprover?.login || !ownerEmail) {
	removeMemberAndCloseModal();
	return;
	}
	// Update approval workflows after approver removal
	const updatedWorkflows = updateWorkflowDataOnApproverRemoval({
	approvalWorkflows,
	removedApprover,
	ownerDetails,
	});
	for (const workflow of updatedWorkflows) {
	if (workflow?.removeApprovalWorkflow) {
	const {removeApprovalWorkflow, ...updatedWorkflow} = workflow;
	removeApprovalWorkflowAction(updatedWorkflow, policy);
	} else {
	updateApprovalWorkflow(workflow, [], [], policy);
	}
	}
	// Remove the member and close the modal
	removeMemberAndCloseModal();
	}, [accountID, approvalWorkflows, ownerDetails, personalDetails, policy, removeMemberAndCloseModal, memberLogin]);

const removeUser = useCallback(() => {
        const ownerEmail = ownerDetails?.login;
        const removedApprover = personalDetails?.[accountID];

        // If the user is not an approver, proceed with member removal
        if (!isApproverUserAction(policy, memberLogin) || !removedApprover?.login || !ownerEmail) {
            removeMemberAndCloseModal();
            return;
        }

        removeMemberAndCloseModal();

        // Update approval workflows after approver removal
        const updatedWorkflows = updateWorkflowDataOnApproverRemoval({
            approvalWorkflows,
            removedApprover,
            ownerDetails,
        });

        for (const workflow of updatedWorkflows) {
            if (workflow?.removeApprovalWorkflow) {
                const {removeApprovalWorkflow, ...updatedWorkflow} = workflow;

                removeApprovalWorkflowAction(updatedWorkflow, policy);
            } else {
                updateApprovalWorkflow(workflow, [], [], policy);
            }
        }
    }, [accountID, approvalWorkflows, ownerDetails, personalDetails, policy, removeMemberAndCloseModal, memberLogin]);

What alternative solutions did you explore? (Optional)

Update workflow success Onyx updates to preserve an existing pendingAction: DELETE instead of always clearing it. This keeps a concurrent removal optimistic state intact and prevents the removed approver from briefly reappearing. We can do this by (1) preserving pendingAction in previousEmployeeList and (2) clearing pendingAction only when it isn’t already DELETE. Apply the same pattern to removeApprovalWorkflow as well.

App/src/libs/actions/Workflow.ts

Lines 99 to 157 in 9618ba6

	function updateApprovalWorkflow(approvalWorkflow: ApprovalWorkflow, membersToRemove: Member[], approversToRemove: Approver[], policy: OnyxEntry<Policy>) {
	if (!policy) {
	return;
	}
	const previousDefaultApprover = getDefaultApprover(policy);
	const newDefaultApprover = approvalWorkflow.isDefault ? approvalWorkflow.approvers.at(0)?.email : undefined;
	const previousEmployeeList = Object.fromEntries(Object.entries(policy.employeeList ?? {}).map(([key, value]) => [key, {...value, pendingAction: null}]));
	const updatedEmployees = convertApprovalWorkflowToPolicyEmployees({
	previousEmployeeList,
	approvalWorkflow,
	type: CONST.APPROVAL_WORKFLOW.TYPE.UPDATE,
	membersToRemove,
	approversToRemove,
	defaultApprover: newDefaultApprover ?? previousDefaultApprover ?? '',
	});
	// If there are no changes to the employees list, we can exit early
	if (isEmptyObject(updatedEmployees) && !newDefaultApprover) {
	return;
	}
	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.APPROVAL_WORKFLOW | typeof ONYXKEYS.COLLECTION.POLICY>> = [
	{
	onyxMethod: Onyx.METHOD.SET,
	key: ONYXKEYS.APPROVAL_WORKFLOW,
	value: null,
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.POLICY}${policy.id}`,
	value: {
	employeeList: updatedEmployees,
	...(newDefaultApprover ? {approver: newDefaultApprover} : {}),
	},
	},
	];
	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.POLICY>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.POLICY}${policy.id}`,
	value: {
	employeeList: previousEmployeeList,
	pendingFields: {employeeList: null},
	...(newDefaultApprover ? {approver: previousDefaultApprover} : {}),
	},
	},
	];
	const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.POLICY>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.POLICY}${policy.id}`,
	value: {
	employeeList: Object.fromEntries(Object.keys(updatedEmployees).map((key) => [key, {pendingAction: null, pendingFields: null}])),
	},
	},
	];

const previousDefaultApprover = getDefaultApprover(policy);
const newDefaultApprover = approvalWorkflow.isDefault ? approvalWorkflow.approvers.at(0)?.email : undefined;
const previousEmployeeList = Object.fromEntries(Object.entries(policy.employeeList ?? {}).map(([key, value]) => [key, {...value}]));
const updatedEmployees = convertApprovalWorkflowToPolicyEmployees({
    previousEmployeeList,
    approvalWorkflow,
    type: CONST.APPROVAL_WORKFLOW.TYPE.UPDATE,
    membersToRemove,
    approversToRemove,
    defaultApprover: newDefaultApprover ?? previousDefaultApprover ?? '',
});

const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.POLICY>> = [
    {
        onyxMethod: Onyx.METHOD.MERGE,
        key: `${ONYXKEYS.COLLECTION.POLICY}${policy.id}`,
        value: {
            employeeList: Object.fromEntries(
                Object.keys(updatedEmployees).map((key) => [
                    key,
                    previousEmployeeList[key]?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE
                        ? {pendingFields: null}
                        : {pendingAction: null, pendingFields: null},
                ]),
            ),
        },
    },
];

[joekaufmanexpensify]

This is a pretty minor issue, but worth cleaning up

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @Pujan92 (External)