[HOLD for payment 2024-04-25] Web - Endless loading on Private section when login via Abracadabra

[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: 1.4.42-0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers): gocemate@gmail.com
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:

Action Performed:

1. Navigate to staging.new.expensify.com
2. Enter gmail account with lot of conversations> Click Continue
3. Navigate to e-mail> copy the login link, change to staging and Enter in new tab
4. Navigate to original Tab and while app still loading navigate to Settings icon
5. Take a note of the Private section

Expected Result:

Private section should load immediately or there should be short time delay

Actual Result:

There is a endless loading on Private section

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

Add any screenshot/video evidence

Bug6381258_1708033813232.staging.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~012818d61c231e3c33
• Upwork Job ID: 1758259134844518400
• Last Price Increase: 2024-02-15

[melvin-bot]

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

[melvin-bot]

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

[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 @NikkiWines (Engineering), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[lanitochka17]

Production:

Bug6381258_1708033813230.production.mp4

[NikkiWines]

I'm able to reproduce the bug on staging and not prod, so this does look to be a blocker. Don't see any recent changes to this view though, at least none that haven't gone to prod already 🤔

[NikkiWines]

Yeah, weird - looks like private_personalDetails is getting set to [] on staging. I can't reproduce on dev, and I don't see any logic that would've modified this recently on newDot. The details are being returned correctly in OpenPersonalDetailsPage though.

FWIW this bug also occurs if you manually paste the magic code, so it's not specific to the Abracadabra flow.

[NikkiWines]

@grgia could this be tied to https://github.com/Expensify/Web-Expensify/pull/40867 by any chance? That's the only recent change I can see to private_personalDetails and the changes are only on staging

[grgia]

@NikkiWines it looks like personalDetails arent loading here, not privatePersonalDetails

[NikkiWines]

@grgia the personal details seem to be ok from my testing - it looks like only the private ones are getting overwritten and in the response to the OpenApp call we can see the following:

Even though the private_personalDetails are correctly being returned earlier in OpenPersonalDetailsPage

It also explains why this bug only occurs if you immediately navigate to the settings page (prompting the OpenPersonalDetailsPage, since the OpenApp call takes a lot longer and can finish after OpenPersonalDetailsPage completes.

[grgia]

ah gotcha, so we need to remove the private personal details from being overwritten in OpenPersonalDetailsPage

[NikkiWines]

Yeah, either prevent them from being over written or have OpenApp return the default empty values (here) for private_personalDetails instead of [] here.

Edit:

I tested this on an account that does have actual private_personalDetails set and OpenApp is still returning [] since the corresponding auth changes aren't live yet.

If we return the default values instead, we'll end up showing blank private_personalDetaiIs if they navigate to the settings page fast enough after logging in, but it'll at least show the form, not a perpetual loading indicator.

Either way, I think updating this line should be updated since we don't want the loading indicator to show forever for users without private_personalDetails set (assuming they navigate to the settings page faster enough)

[NikkiWines]

Oh also not a newDot blocker since this is due to backend changes 👍

[damadoko]

Proposal

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

Endless loading on personal private section when logging

What is the root cause of that problem?

.

1. When user click fast enough after login via Abracadabra, the OpenPersonalDetailsPage was called before OpenApp.
2. OpenPersonalDetailsPage return appropriate private_personalDetails data.
3. OpenApp return [] for private_personalDetails data (and override the appropriate one).
4. Personal private section keep loading because below line fallback to true.

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

Line 106 in a6fe014

const isLoadingPersonalDetails = lodashGet(props.privatePersonalDetails, 'isLoading', true);

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

Currently, user can navigate to setting page even when the user's avatar icon is show loading.
=> We need to prevent navigate action when loading to ensure OpenPersonalDetailsPage can only be called after OpenApp

The condition should be apply in line 44:

App/src/pages/home/sidebar/PressableAvatarWithIndicator.js

Lines 43 to 50 in a6fe014

	const showSettingsPage = useCallback(() => {
	if (isCreateMenuOpen) {
	// Prevent opening Settings page when click profile avatar quickly after clicking FAB icon
	return;
	}
	Navigation.navigate(ROUTES.SETTINGS);
	}, [isCreateMenuOpen]);

It should be

const shouldShowLoading = isLoading && !currentUserPersonalDetails.avatar;
const showSettingsPage = useCallback(() => {
  if (isCreateMenuOpen || shouldShowLoading) {
    return;
  }

What alternative solutions did you explore? (Optional)

Above solution correct behavior of loading element. Anyway, we can change OpenApp in the BE too. Both fix the issue

[grgia]

Apologies I was wrapped up yesterday, Looking at this I think we can deprecate that command in App now that my auth changes have deployed

[grgia]

I can take this @NikkiWines

[melvin-bot]

This issue has not been updated in over 15 days. @s77rt, @grgia eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

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

• Remove unnecessary calls to OpenPrivatePersonalDetailsPage #37047

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

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

• @s77rt requires payment (Needs manual offer from BZ)

[melvin-bot]

Issue is ready for payment but no BZ is assigned. @joekaufmanexpensify you are the lucky winner! Please verify the payment summary looks correct and complete the checklist. Thanks!

[melvin-bot]

Payment Summary

Upwork Job

• C+: @s77rt paid $500 via Upwork (LINK)

BugZero Checklist (@joekaufmanexpensify)

• I have verified the correct assignees and roles are listed above and updated the neccesary manual offers
• I have verified that there are no duplicate or incorrect contracts on Upwork for this job (https://www.upwork.com/ab/applicants/1758259134844518400/hired)
• I have paid out the Upwork contracts or cancelled the ones that are incorrect
• I have verified the payment summary above is correct

[joekaufmanexpensify]

Only payment needed here is $500 to @s77rt for C+ via Upwork (this issue was created before default price lowered to $250).

[joekaufmanexpensify]

OG upwork job is closed. new one is here: https://www.upwork.com/jobs/~01058cf92b6ef09600

[joekaufmanexpensify]

@s77rt offer for $500 sent!

[s77rt]

@joekaufmanexpensify Accepted! Thanks!

[joekaufmanexpensify]

@s77rt $500 sent and contract ended!

[joekaufmanexpensify]

Upwork job closed.

[joekaufmanexpensify]

All set, thanks everyone!