[$500] Mac/Safari - Login - App crashed when login to App

[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.16-4
Reproducible in staging?: Y
Reproducible in production?: Y
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
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:

Issue found when executing PR #33238

Action Performed:

Precondition: Safari version: 15.5

1. Navigate to ND https://staging.new.expensify.com/
2. Login with account

Expected Result:

User should be login

Actual Result:

App crashed. "Uh-oh, something went wrong!. If the problem persists, reach out to concierge@expensify.com"
and two buttons are present refresh and Sign out.

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: Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6325011_1703349983889.33238_Mac_Safari_15.5.mp4

logs 2.txt

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01c0a43e9aa7cd2f5f
• Upwork Job ID: 1738606471051292672
• Last Price Increase: 2023-12-30

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @anmurali (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

[melvin-bot]

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

[bernhardoj]

Looks like #33238 hasn't deployed to staging yet.

[rojiphil]

Looks like #33238 hasn't deployed to staging yet.

This issue is unrelated to the mentioned PR

[rojiphil]

Proposal

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

On a fresh signing with a new account, an unintended report is attempted to be displayed in central pane. This is the problem we are trying to solve.

What is the root cause of that problem?

When we load the App for the very first time using a new account (i.e. this account was not used for signin before), the openApp will also return Domain Room as shown in attached image below. Since the App is loaded for the first time, there will be no reportID specified in routes param due to which findLastAccessedReport will be used here to determine the last accessed report id via ReportScreenIDSetter. Here, isFirstTimeNewExpensifyUser will be true as this is a first time new user and ignoreDomainRooms would be true as we want to ignore domain rooms. Since we ignore the domain rooms only after the check for isFirstTimeNewExpensifyUser, the domain room report id is returned as the last accessed id thereby resulting in the display of domain room in central pane. This is the root cause of the problem.

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

To solve the problem, we should, first, filter out the domain rooms before deciding on the last accessed report id for the first time Expensify user here like this:

if (ignoreDomainRooms) {
    // We allow public announce rooms, admins, and announce rooms through since we bypass the default rooms beta for them.
    // Check where ReportUtils.findLastAccessedReport is called in MainDrawerNavigator.js for more context.
    // Domain rooms are now the only type of default room that are on the defaultRooms beta.
    sortedReports = sortedReports.filter(
        (report) => !isDomainRoom(report) || getPolicyType(report, policies) === CONST.POLICY.TYPE.FREE || hasExpensifyGuidesEmails(report?.participantAccountIDs ?? []),
    );
}

if (isFirstTimeNewExpensifyUser) {
    if (sortedReports.length === 1) {
        return sortedReports[0];
    }

    return adminReport ?? sortedReports.find((report) => !isConciergeChatReport(report)) ?? null;
}

What alternative solutions did you explore? (Optional)

[situchan]

@rojiphil should these conditions meet to reproduce this issue?

• old macOS
• new account

[rojiphil]

@rojiphil should these conditions meet to reproduce this issue?

• old macOS
• new account

While new account is required here, I am unsure of the macOS/Safari criteria. I used macOS Ventura 13.2.1/v16.3 Safari.
But, looking at the issue here, it seems unrelated to OS/Safari version.

[situchan]

I am not able to reproduce on both old (16.0) and new (17.0) safari. Tested with new account

[rojiphil]

I am not able to reproduce on both old (16.0) and new (17.0) safari. Tested with new account

hmm.. That's interesting. Let me have a look again.

[rojiphil]

@situchan
Can you please check if you get two reports as a response from openApp as mentioned in my proposal?

[rojiphil]

Maybe this has to do with domain since we are dealing with a domain room.
My test accounts have a custom domain.

[melvin-bot]

@anmurali, @getusha Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[getusha]

I am also not able to reproduce this, we can close it.

[rojiphil]

@getusha
I can reproduce this consistently.
Did you happen to try a test account with a custom domain?

[getusha]

Did you happen to try a test account with a custom domain?

@rojiphil could you please explain what a custom domain is?

[rojiphil]

could you please explain what a custom domain is?

@getusha
Let's take a test account (say user@mydomain.com).
Here, mydomain.com is what I referred to as the custom domain.

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot]

@anmurali, @getusha Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

@anmurali, @getusha Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[anmurali]

It's slow to load but I can login. Closing this issue.

[rojiphil]

It's slow to load but I can login. Closing this issue.

@anmurali

I can still reproduce the issue on the latest staging. Here is an attached video for the same.

Since you would have an account with expensify.com domain, can you please try creating a new test account with expensify.com domain on staging.new.expensify.com?
I think this will reproduce the problem here.

33551-issue.mp4