[HOLD for payment 2024-04-15] [Simplified Collect][Members] Members list does not update to show the new admin and owner

[kbecciv]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 1.4.57-0
Reproducible in staging?: y
Reproducible in production?: new feature
Issue reported by: Applause - Internal Team

Action Performed:

Precondition:

• User is an admin of a Collect workspace, but not an owner.

1. Go to staging.new.expensify.com.
2. Go to Profile > Workspaces > Collect workspace.
3. Go to Members.
4. Click on the owner in the list.
5. Click Transfer owner.
6. Go through the steps.
7. Close the RHP.

Expected Result:

The Members list will update to show the new admin and owner.

Actual Result:

The Members list does not update to show the new admin and owner. It only updates after refreshing the page.

Workaround:

n/a

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6428620_1711540656330.owner_list_not_update.mp4

View all open jobs on GitHub

[kbecciv]

We think that this bug might be related to #wave-control

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

[melvin-bot]

Triggered auto assignment to @nkuoch (Engineering), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[nkuoch]

@luacmartins Is this from #37869?
Can we remove the DeployBlocker label and let Burczu fix it?

[luacmartins]

Yes, we can remove the label and I can take this over since it's from the Simplified Collect project. Thanks for the ping!

[luacmartins]

I didn't see this behavior in my tests. @burczu can you reproduce?

[luacmartins]

I took a quick look at this. It works for me locally, but for some reason in staging all other policy members seem to get the update except for the user making the request.

@iwiznia @danieldoglas any ideas why this update is being delivered to other policy members but not the user making the request since they are also a policy member? This seems to work locally, but not in staging

[danieldoglas]

@luacmartins was the update returned in the HTTPs response? It should, but if it wasn't, that update won't be sent though pusher to the requester client too.

[luacmartins]

@danieldoglas it was not. The http response has an empty array, but other members get the update.

[danieldoglas]

that's indeed very strange. Anything that is inserted in onyx in which the user is also included should be returned in the HTTP request. So that's where the problem is... not sure why that would happen in staging but not in dev.

[burczu]

@luacmartins Could you please assign it to me? I think the problem comes from my incorrect assumption when creating mocked API responses - I presumed that once the change owner request is successful, the API will return updated list of members and the related Policy onyx key will update automatically (something like in my example mocked response, I've attached below). But I think we agreed in the proposal document that it will just clear the errorFields object, so the update should occur on the frontend side - am I right?

On the other hand, maybe this should be done on the backend side? Because the update will be visible for other clients instantly then?

return new Promise((resolve) => {
    setTimeout(() => {
        resolve({
            jsonCode: 200,
            onyxData: [
                {
                    key: 'policy_861B441F4C96AD1E',
                    onyxMethod: 'merge',
                    value: {
                        owner: '[email protected]',
                        ownerAccountID: 16388108,
                        errorFields: null,
                    },
                },
            ],
        });
    }, 2000);
});

[burczu]

@luacmartins I've just added a draft PR with the change that should fix the issue on the front end side.

[luacmartins]

@burczu I think setting it optimistically makes sense too, but I think there's something up with the API side too. I'll investigate this again now.

[luacmartins]

Ok, here's a video of the request in staging. We can see that the response for the user making the request is empty, but in the end of the video we can see the roles for the other user being updated (after I pointed that out in the video lol), so the Onyx update seems to be sent correctly for that user. This are the request logs, nothing stood out to me.

Screen.Recording.2024-03-28.at.11.47.01.AM.mov

Here's the same request made in dev. We can see that the user making the request also receives the update.

dev.mov

[luacmartins]

Hmm I think I see an issue, but it's hard to tell if that's the right fix since it works in dev. Gonna put up a PR.

[trjExpensify]

Is this one done and over the line, or what's left to tackle?

[burczu]

@trjExpensify On the frontend side the issue is fixed, but @luacmartins wanted also to fix this on the backend side, and I don't know if it's done already.

[luacmartins]

This is fixed! We're good to close since there's no C+ payment due.

[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 1.4.60-13 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• #39057 - Members list does not update to show the new admin and owner #39159

If no regressions arise, payment will be issued on 2024-04-15. 🎊