[$250] Settings - Infinite loading on Private section if notification is received

[izarutskaya]

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

---

Found when validating PR : #37967

Version Number: 1.4.54.0
Reproducible in staging?: Y
Reproducible in production?: Y
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause-Internal team

Action Performed:

Precondition: Notifications should be enabled.

1. Log out and close all Chrome windows
2. Open Chrome and log in with a new expensifail user
3. Navigate to Account settings - Profile

Expected Result:

The section should load.

Actual Result:

Infinite loading on Profile - Private section if notification is received from Concierge. It loads at first but starts spinning after receiving the notification.
I'm unable to check prod as I'm not getting a notification there.

Workaround:

Unknown

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

Bug6418826_1710839027026.bandicam_2024-03-19_09-55-27-686.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~011ce0234e9c243c7c
• Upwork Job ID: 1775984986283810816
• Last Price Increase: 2024-04-04

[melvin-bot]

Triggered auto assignment to @isabelastisser (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[izarutskaya]

We think this issue might be related to the #collect project.

[nkdengineer]

Proposal

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

• Settings - Infinite loading on Private section if notification is received

What is the root cause of that problem?

• When signing in the app, the API OpenApp is called. It returns private_personalDetails: [].
• Then if we open the setting profile, the API OpenPersonalDetailsPage is called. It returns:

{
  "legalFirstName": "",
  "legalLastName": "",
  "dob": "",
  "address": {
    "street": "",
    "city": "",
    "state": "",
    "zip": "",
    "country": ""
  },
  "isLoading": false
}

• If the API OpenPersonalDetailsPage is called successfully before the other one, OpenApp, the bug will occur. Because:
• In the ProfilePage, we use the below logic to decide whether we should display the loading indicator or not:
  

  App/src/pages/settings/Profile/ProfilePage.tsx

  Line 73 in 51ef6c1

  const isLoadingPersonalDetails = privatePersonalDetails?.isLoading ?? true;

  
  and in this case, isLoadingPersonalDetails is always true because privatePersonalDetails: []

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

• We already have logic to call the OpenPersonalDetailsPage again if privatePersonalDetails is not available as below:
  

  App/src/hooks/usePrivatePersonalDetails.ts

  Lines 11 to 18 in 8206580

  	useEffect(() => {
  	const personalDetails = PersonalDetails.getPrivatePersonalDetails();
  	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
  	if (network?.isOffline || (Boolean(personalDetails) && personalDetails?.isLoading !== undefined)) {
  	return;
  	}
  	PersonalDetails.openPersonalDetails();

  
  but it is not called again when the privatePersonalDetails is changed.
• So the solution is that we should add the privatePersonalDetails to the above useEffect 's dependencies.
• For example, instead of using usePrivatePersonalDetails like here, we can use:

  useEffect(() => {
        if (network?.isOffline || (Boolean(personalDetails) && personalDetails?.isLoading !== undefined)) {
            return;
        }

        PersonalDetails.openPersonalDetails();
    }, [network?.isOffline, personalDetails]);

• Note: the above is just a quick code change to test.

What alternative solutions did you explore? (Optional)

• NA

[isabelastisser]

Added to wave collect.

[trjExpensify]

👋 I see this one was added to Hot Picks. Is it a backend issue, or is it frontend and can go External?

[nkdengineer]

I think it is FE issue based on RCA here

[trjExpensify]

Cool, let's send it External!

[melvin-bot]

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

[melvin-bot]

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

[Pujan92]

I can reproduce with the steps

1. Logout
2. Try to open profile link directly(eg. https://staging.new.expensify.com/settings/profile)
3. Login with the account where private details haven't been updated yet
4. infinite loading can be observed for the private section

[Pujan92]

RCA mentioned by @nkdengineer looks correct where private_personalDetails merged with [] with the later call of OpenApp api.

I think the issue is with the OpenApp API private_personalDetails return type, it should be consistent by providing the object {} instead []. With that, I believe this should require a BE fix. @isabelastisser @trjExpensify Can we add engineering label here to confirm?

Video

Screen.Recording.2024-04-08.at.19.55.48.mov

[nkdengineer]

@Pujan92 I think if we just "providing the object {} instead []", the issue is not fixed

[isabelastisser]

Bump @Expensify/applauseleads to retest this, please. Thanks!

[nkdengineer]

FYI the fix went to prod 1 week ago

@Beamanator What is the output after fixing? The private_personalDetails is always object {} instead of [] in OpenApp API, right?

[Beamanator]

@nkdengineer exactly, technically private_personalDetails should include your private personal details IF set, but if you haven't set any, it should return {} instead of []

[Beamanator]

Adding retest-weekly to hopefully get applause's attention to retest! 🙏

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[isabelastisser]

Not overdue.

[Beamanator]

Niiiice, maybe we wait till 1 more retest then close if it's fixed 👍

[isabelastisser]

@mvtglobally can you please provide an update? Is it fixed? Thanks!

[isabelastisser]

Bump @mvtglobally

[mvtglobally]

Issue not reproducible during KI retests. (Second week)

[Beamanator]

Looks like we'll close this this week 🙏

[mvtglobally]

Issue not reproducible during KI retests. (Third week)

[Beamanator]

Nice, closing!