[Due for payment 2025-05-22] [$250] Remove unnecessary Read api call s on the workspace features pages

[mountiny]

Coming from here

On some of the workspace feature pages, we call the OpenPolicyFeatureX API command additionally when the RHP modal is closed.

For example:

1. Go to Members page
2. Open the workspace member detail page in RHP
3. Close the RHP
4. Notice in the Networks tab that the OpenPolicyFeatureX command was called again

Similar thing is happening on the report fields page too and possibly on some other pages too. It does not happen on all the pages so potentially the solution is quick

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021917178062594162758
• Upwork Job ID: 1917178062594162758
• Last Price Increase: 2025-04-29

Issue Owner

Current Issue Owner: @RachCHopkins

Issue Owner

Current Issue Owner: @martasudol

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Current assignee @mountiny is eligible for the AutoAssignerNewDotQuality assigner, not assigning anyone new.

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

[ishakakkad]

Proposal

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

Remove unnecessary Read api call s on the workspace features pages

What is the root cause of that problem?

For some of the pages we use useFocusEffect for ex, here and some of the pages we used isFocused state inside the useEffect for ex, here . So whenever page is focused we call the API to get the data.

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

To fix this issue we need to replace to useFocusEffect with useEffect. And whenever we use isFocused we should remove that and load the data only when page first time loads or whenever needed (can be checked during implementation)

1. replace useFocusEffect with useEffect

App/src/pages/workspace/WorkspaceOverviewPage.tsx

Lines 152 to 156 in d391099

	useFocusEffect(
	useCallback(() => {
	fetchPolicyData();
	}, [fetchPolicyData]),
	);

2. following code should not be execute when isFocused changed.

App/src/pages/workspace/WorkspaceMembersPage.tsx

Line 186 in d391099

getWorkspaceMembers();

Make same kind of changes in other pages whenever needed.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

NA UI issue

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[nabi-ebrahimi]

Proposal

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

On some workspace feature pages (e.g., Members and Report Fields), the OpenPolicyFeatureX API command is unnecessarily triggered when the Right-Hand Panel (RHP) is closed. This results in redundant API calls that waste bandwidth and can impact performance.

What is the root cause of that problem?

A useEffect hook that listens to the isFocused state is calling getWorkspaceMembers() whenever the focus changes. Since closing the RHP updates the focus, this effect is incorrectly triggered even when no meaningful data update is required, leading to the repeated API call.

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

We should update the following useEffect block: here

Original:

useEffect(() => {
    if (!isFocused) {
        setSelectedEmployees([]);
        return;
    }
    getWorkspaceMembers();
}, [isFocused]);

Updated:

useEffect(() => {
    if (!isFocused) {
        setSelectedEmployees([]);
        return;
    }

    // Avoid unnecessary API call if employee list already exists
    if (isEmptyObject(policy?.employeeList)) {
        getWorkspaceMembers();
    }
}, [isFocused, policy?.employeeList]);

This ensures getWorkspaceMembers() is only called when the page gains focus and the employee list is empty—avoiding the redundant API call on RHP close.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N/A

What alternative solutions did you explore? (Optional)

[mountiny]

This is handled by callstack as the initial assignment suggests.

We need to make sure this is called when the page is opened/ navigated from deelinks and in narrow view too

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

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

• fix: reduced unnecessary API calls on workspace features #61169

If no regressions arise, payment will be issued on 2025-05-22. 🎊

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

• @s77rt requires payment through NewDot Manual Requests
• @martasudol does not require payment (Contractor)

[melvin-bot]

@s77rt @RachCHopkins @s77rt 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]

[s77rt]

BugZero Checklist:

• [Contributor] Classify the bug:

Bug classification

Source of bug:

• 1a. Result of the original design (eg. a case wasn't considered)
• 1b. Mistake during implementation
• 1c. Backend bug
• 1z. Other:

Where bug was reported:

• 2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
• 2b. Reported on staging (eg. found during regression or PR testing)
• 2d. Reported on a PR
• 2z. Other: Slack thread while working on fixing another similar bug

Who reported the bug:

• 3a. Expensify user
• 3b. Expensify employee
• 3c. Contributor
• 3d. QA
• 3z. Other:

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

  Link to comment: Fix: Read API is not triggered consistently when switching between features of a Collect workspace #38613 (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.

  Bug requires regression test: No. I don't think this qualifies for a test