[Hold for #27168] [$1000] Payments - App crashes when navigating to enable payments page before logging in

[lanitochka17]

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

---

Action Performed:

1. Log out of your account
2. Go to `/enable-payments
3. Login with another account

Expected Result:

There should be no crash and it should show the page

Actual Result:

The app crashes

Workaround:

Unknown

Platforms:

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

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• Windows/ Chrome
• MacOS / Desktop

Version Number: 1.3.57-5

Reproducible in staging?: Yes

Reproducible in production?: Yes

If this was caught during regression testing, add the test name, ID and link from TestRail:

Email or phone of affected tester (no customers):

Logs: https://stackoverflow.com/c/expensify/questions/4856

Notes/Photos/Videos: Any additional supporting documentation

Screen.Recording.2023-08-18.at.9.01.47.PM.mov

Recording.3000.mp4

Expensify/Expensify Issue URL:

Issue reported by: @esh-g

Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1692372864188139

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0185374146bc15359c
• Upwork Job ID: 1696179031964413952
• Last Price Increase: 2023-08-28
• Automatic offers:
• cubuspl42 | Reviewer | 26485367
• hoangzinh | Contributor | 26485370
• esh-g | Reporter | 26485371

[melvin-bot]

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

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[hungvu193]

Proposal

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

Payments - App crashes when navigating to enable payments page before logging in

What is the root cause of that problem?

Problem came from this function when we tried to get the indexOf from undefined value.

App/src/pages/EnablePayments/AdditionalDetailsStep.js

Line 192 in c169952

defaultValue={PersonalDetails.extractFirstAndLastNameFromAvailableDetails(currentUserPersonalDetails).firstName}

App/src/libs/actions/PersonalDetails.js

Line 100 in c169952

const firstSpaceIndex = displayName.indexOf(' ');

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

We should add loading check inside our AdditionalDetailsStep to prevent this crash:

// personalDetailsList from ONYXKEYS.PERSONAL_DETAILS_LIST
if (!_.isPersonalDetailsReady(personalDetailsList) || _.isEmpty(currentPersonalDetails)) {
return <FullscreenLoading />

}

function isPersonalDetailsReady(personalDetails) {
    return !_.isEmpty(personalDetails) && _.some(_.keys(personalDetails), (key) => personalDetails[key].accountID);
}

Also adding a defaultValue for displayName as empty string inside extractFirstAndLastNameFromAvailableDetails function.

Other screens that used the currentPersonalDetails can also face this issue, we can apply this fix for those screens too.

What alternative solutions did you explore? (Optional)

N/A

[pradeepmdk]

Proposal

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

App crashes when navigating to the enable payments page before logging

What is the root cause of that problem?

when login currentUserPersonalDetails having only accountID remaining is not set

Why means after signin it will fetch personaldeatils information from back end and set to onyx and before sign we are trying to reach /enabled-payments page so after signin it will directly render to that page.

before loading currentUserPersonalDetails fully page tries to render
const currentUserPersonalDetails = useMemo(() => ({...props.personalDetails[accountID], accountID}), [props.personalDetails, accountID]);

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

1. We should remove accountID here and check the the empty of currentUserPersonalDetails in the additionalDetailsSteps page
   const currentUserPersonalDetails = useMemo(() => ({...props.personalDetails[accountID], accountID}), [props.personalDetails, accountID]);

_.isEmpty(currentPersonalDetails)) {
return <FullscreenLoading />

}

2. we should declare all the props empty in WithCurrentUserPersonalDetails
   Or we can declare empty in request param
   extractFirstAndLastNameFromAvailableDetails({login, displayName='', firstName='', lastName=''})

[hoangzinh]

Proposal

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

Payments - App crashes when navigating to enable payments page before logging in

What is the root cause of that problem?

• The error come from this line

  App/src/pages/EnablePayments/AdditionalDetailsStep.js

  Line 192 in c029dc5

  defaultValue={PersonalDetails.extractFirstAndLastNameFromAvailableDetails(currentUserPersonalDetails).firstName}

  
  The currentUserPersonalDetails is null so it raises error when we call function extractFirstAndLastNameFromAvailableDetails

• The root cause is because after login, the OpenApp API is not completed yet, so the personalDetailsList is not ready yet => We couldn't get the currentUserPersonalDetails in this line, so it will be null:

  App/src/components/withCurrentUserPersonalDetails.js

  Line 39 in c029dc5

  const currentUserPersonalDetails = useMemo(() => ({...props.personalDetails[accountID], accountID}), [props.personalDetails, accountID]);

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

In the EnablePaymentsPage component, we should check if the Onyx key ONYXKEYS.IS_LOADING_REPORT_DATA is true, we should display loading page in this line

App/src/pages/EnablePayments/EnablePaymentsPage.js

Lines 53 to 55 in c029dc5

	if (_.isEmpty(this.props.userWallet)) {
	return <FullScreenLoadingIndicator />;
	}

So it only renders child components whenever the OpenApp data is ready.

[melvin-bot]

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

[melvin-bot]

Current assignee @NicMendonca is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

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

[NicMendonca]

@cubuspl42 some proposals for you to review here! ^

[cubuspl42]

@NicMendonca This is next on my list! I'll start reviewing them tomorrow morning, i.e. in ~10 hours

[cubuspl42]

@hungvu193 While the solution might work on the technical level, your root cause analysis is a bit shallow. You focused on what's happening on the programming language level, not on what's happening from the broader perspective and why.

@hoangzinh Your root cause analysis sounds reasonable. Could you elaborate a bit on the solution part? As I understand it, the missing (not-yet-loaded) data is the current user personal details. That doesn't sound like a part of the "report data", what am I missing? Is the semantics of IS_LOADING_REPORT_DATA key different than what could be concluded from the name?

[hungvu193]

@hungvu193 While the solution might work on the technical level, your root cause analysis is a bit shallow. You focused on what's happening on the programming language level, not on what's happening from the broader perspective and why.

I proposed using isLoadingReportData from my first proposal, but I feel that's more meaning full to use isPersonalDetailsReady, because it's better to avoid the weird dependency when the page doesn't appear to actually require anything about the report.

[hoangzinh]

@cubuspl42 Yeah, the Onyx key name IS_LOADING_REPORT_DATA is quite of confusing. Is it the flag to check whether the OpenApp API is finish or not. The OpenApp API includes personalDetailsList

[hoangzinh]

I think we should check above flag IS_LOADING_REPORT_DATA because it's a correct signal to check whether the API to fetch personalDetailsList data is completed. Moreover, later on, if the page depends on other needed data in the API above, we can cover it by the single flag IS_LOADING_REPORT_DATA as well.

[cubuspl42]

I say we go with the @hoangzinh proposal. The root cause analysis is the clearest and the proposed solution sounds reasonable to me.

C+ reviewed 🎀 👀 🎀

[melvin-bot]

Triggered auto assignment to @robertjchen, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[robertjchen]

Thanks, reviewing this now

[robertjchen]

Agreed with @hoangzinh 's analysis and approach 👍

[hoangzinh]

Somehow in latest main branch, after sign in, the App could not redirect to the /enable-payments. Is it a bug or there is something change recently? I checked the code and it seems we only support open a chat report after sign in/sign up atm

App/src/Expensify.js

Lines 170 to 173 in 8150ce0

	Linking.getInitialURL().then((url) => {
	DemoActions.runDemoByURL(url);
	Report.openReportFromDeepLink(url, isAuthenticated);
	});

cc @cubuspl42 @robertjchen

[cubuspl42]

I know that there were some last minute changes to navigation before the conference. The "demos" mentioned in your snippet are supposed to be gone soon, if I understand this right.

[hoangzinh]

I worry that we can't reproduce this bug anymore. cc @esh-g if you still reproduce this bug.

[cubuspl42]

I also asked on Slack whether the change is intentional

[cubuspl42]

Could we please hold this on this bug? I know that the PR is already created, but it's not our fault that that bug was introduced, and it makes difficult to properly verify the fix for our issue.

Unfortunately, there's still no GH for the mentioned thing, so we can "[HOLD Broken deeplinks]" or something like that.

[cubuspl42]

This is the GH issue: #27168

[cubuspl42]

@NicMendonca Please add a hold on #27168

[melvin-bot]

This issue has not been updated in over 15 days. @robertjchen, @cubuspl42, @hoangzinh, @NicMendonca 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!

[cubuspl42]

Still on hold

[robertjchen]

still on hold

[hoangzinh]

@cubuspl42 @robertjchen it looks like it's fixed somewhere. I couldn't reproduce this issue in the latest main.

Screen.Recording.2023-11-30.at.23.57.10.mov

[cubuspl42]

Conclusion: if you hold for long enough, the issue fixes itself 😅

[hoangzinh]

So I think the next step should be payment, and then closing this issue 🤔

[cubuspl42]

It's a delicate topic, but there probably will be no payment. Unless it's a very special case (which this one isn't), payments are done for merged PRs. I'm sorry about this, but this is one of the inherent risks associated with our process.

[hoangzinh]

Ah @cubuspl42 fyi, this case is the same as step 19. in Updated process section of https://docs.google.com/document/d/1BvohU05MTaHnjOD_vwJv_aqDAirv-ChkyRnKCAvOVyQ

[hoangzinh]

cc @NicMendonca can you help process payment here then we can close this issue? ^ Thanks

[cubuspl42]

It seems you're right

[NicMendonca]

everyone's been paid!