[HOLD for payment 2024-01-31] [$500] New organic sign-up dropped in an “Hmm.. it’s not there” chat

[m-natarajan]

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:
Reproducible in staging?: needs reproduction
Reproducible in production?: needs reproduction
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: @trjExpensify
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1703070069444339

Action Performed:

1. Go to staging.new.expensify.com
2. Sign-up with a private domain email address not on the defaultRoom beta > get the magic code from email
3. Enter the magic code > land in NewDot

Expected Result:

An organic sign-up should land in the Concierge chat on first sign-in with the global create FAB expanded

Actual Result:

• Concierge chat not highlighted in the LHN, and the main pane is a “Hmm.. it’s not there” chat screen (which we reasonable believe to be the default domain room as noted here).
• Clicking on the Concierge chat row, the reportID in the URL updates to the Concierge chat reportID and the main pane updates: https://staging.new.expensify.com/r/8392311097742670

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

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01b5beb5290c8be9e8
• Upwork Job ID: 1743242903474585600
• Last Price Increase: 2024-01-05
• Automatic offers:
• rojiphil | Contributor | 28106268

[melvin-bot]

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

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

[melvin-bot]

@miljakljajic Huh... This is 4 days overdue. Who can take care of this?

[melvin-bot]

@miljakljajic 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

[melvin-bot]

@miljakljajic 10 days overdue. I'm getting more depressed than Marvin.

[miljakljajic]

Just came back online today - will try to reproduce this afternoon

[miljakljajic]

Couldn't repro on staging or production - asked for others to try on the original slack thread

[melvin-bot]

@miljakljajic this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[trjExpensify]

Commented in the thread, still reproducible for me:

[trjExpensify]

Account I used to test on this one was tom+hmmtest2@trj.chat if helpful.

[miljakljajic]

@trjExpensify am I following the repro steps correctly? I get the expected result when I try with milja.nastasia+155@gmail.com and various other email addresses.

Organic.Signup.mp4

[trjExpensify]

Steps are correct. Did you try a private domain email address as well?

[trjExpensify]

After doing some more testing in the thread, I think for some reason we're trying to send a new private domain email sign-up into the default domain room on first sign-in. As my private domain doesn't have access to the defaultRooms beta which is what is hiding that unreleased room from the masses, I'm hitting the "Hmm.. it's not there!" screen as I'm dropped into that chat.

As you can see from this video from @m-natarajan attempting a reproduction on @applause.expensifail.com domain which has access to all betas, they get dropped into the domain default room.

Recording.341.mp4

So the investigation is to figure out when and why that started to happen. The fix is to stop doing that and land a new private domain organic sign-up in the Concierge DM, like we do a public domain sign-up.

CC: @jasperhuangg for visibility as someone with experience with rooms.

[trjExpensify]

Updated the OP for you, Milja. Let's get eyes on it from the community, adding External.

[melvin-bot]

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

[melvin-bot]

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

[rojiphil]

Proposal

Bringing the proposal from here

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)

[trjExpensify]

Nice, thanks for digging in! Have we identified which PR caused this regression as well? It must be fairly recent.

[rojiphil]

Nice, thanks for digging in! Have we identified which PR caused this regression as well? It must be fairly recent.

Looks to me that a BE PR decided to send this sometime recently. And FE will show the domain room report if it comes.

[jasperhuangg]

Hey guys sorry, been OOO.

@rojiphil Can you confirm which logic in this function we're getting into that's causing this bug?

App/src/libs/ReportUtils.ts

Lines 910 to 937 in 3033f99

	let sortedReports = sortReportsByLastRead(reports, reportMetadata);
	let adminReport: OnyxEntry<Report> | undefined;
	if (openOnAdminRoom) {
	adminReport = sortedReports.find((report) => {
	const chatType = getChatType(report);
	return chatType === CONST.REPORT.CHAT_TYPE.POLICY_ADMINS;
	});
	}
	if (isFirstTimeNewExpensifyUser) {
	if (sortedReports.length === 1) {
	return sortedReports[0];
	}
	return adminReport ?? sortedReports.find((report) => !isConciergeChatReport(report)) ?? null;
	}
	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 ?? []),
	);
	}
	return adminReport ?? sortedReports.at(-1) ?? null;

I'm unable to reproduce it with a fresh account on a private domain, is this a race condition of some sort? I'm creating an email with https://www.emailondeck.com/

[jasperhuangg]

We should definitely be redirecting first-time Expensify users to their Concierge chat upon their first-sign in, and not the private domain chat.

[rojiphil]

@jasperhuangg

We should definitely be redirecting first-time Expensify users to their Concierge chat upon their first-sign in, and not the private domain chat.

This is the Issue 1 that I was referring to here. Also, please refer to my follow-up comment here for completeness.
Does this make sense?

Can you confirm which logic in this function we're getting into that's causing this bug?

As mentioned in my proposal here, first time users would reach here but we have still not skipped the domain room as done here because of which the private domain room will get displayed.

[jasperhuangg]

@rojiphil Got it, that makes sense. I think your proposal should work then!

[melvin-bot]

📣 @rojiphil 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job
Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

[rojiphil]

@mananjadhav
PR is ready for review
Kindly review

[mvtglobally]

Issue not reproducible during KI retests. (Second week)

[miljakljajic]

@mvtglobally can you confirm you're using a private domain to try and reproduce? Still reproducible for me whenever I sign up with a private email address.

2024-01-22_12-22-46.mp4

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

• ignore domain room reports for first time user sign in #34732

If no regressions arise, payment will be issued on 2024-01-31. 🎊

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

• @rojiphil requires payment automatic offer (Contributor)
• @mananjadhav requires payment through NewDot Manual Requests

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@mananjadhav] The PR that introduced the bug has been identified. Link to the PR:
• [@mananjadhav] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@mananjadhav] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@mananjadhav] Determine if we should create a regression test for this bug.
• [@mananjadhav] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@miljakljajic] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[cristipaval]

tomorrow is the payment day, melv

[miljakljajic]

@rojiphil - paid in upwork

Summary for @mananjadhav below:

@mananjadhav is owed 500 USD for their role in reviewing the code. Please request payment in ND.

[JmillsExpensify]

$500 approved for @mananjadhav based on summary above.