[HOLD for payment 2024-07-17] [$250] Profile - Profile changes to Hidden and "Email not found" error when messaging Hidden user

[lanitochka17]

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

---

Version Number: 1.4.80-9
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Issue reported by: Applause - Internal Team

Action Performed:

1. Go to staging.new.expensify.com
2. Go to FAB > Start chat
3. Enter a non-existing email
4. Select the email
5. Quickly click on the chat header after landing on the DM
6. After the profile changes to Hidden, click Message

Expected Result:

In Step 5, the user profile RHP will remain unchanged

Actual Result:

In Step 5, the user profile RHP changes to Hidden
When clicking Message, app redirects to chat with another user with the error "Email not found"

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

Bug6504945_1717762402806.bandicam_2024-06-07_20-08-22-644.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~018004b4dcf5d57a3b
• Upwork Job ID: 1800107416738330577
• Last Price Increase: 2024-07-01
• Automatic offers:
• ZhenjaHorbach | Reviewer | 102957514
• bernhardoj | Contributor | 102957518

Issue Owner

Current Issue Owner: @twisterdotcom

[melvin-bot]

Triggered auto assignment to @laurenreidexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[lanitochka17]

@laurenreidexpensify FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[lanitochka17]

We think that this bug might be related to #vip-vsp

[bernhardoj]

Proposal

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

Profile page changes to hidden and error when pressing Message on a new user.

What is the root cause of that problem?

When we start a new chat, we will create an optimistic personal detail for the user. We actually have a disabled condition to disable the press when the user is optimistic.

App/src/pages/home/HeaderView.tsx

Line 258 in bb6e7eb

disabled={shouldDisableDetailPage}

App/src/libs/ReportUtils.ts

Lines 1124 to 1132 in bb6e7eb

	function shouldDisableDetailPage(report: OnyxEntry<Report>): boolean {
	const participantAccountIDs = Object.keys(report?.participants ?? {}).map(Number);
	if (isChatRoom(report) || isPolicyExpenseChat(report) || isChatThread(report) || isTaskReport(report)) {
	return false;
	}
	if (participantAccountIDs.length === 1) {
	return isOptimisticPersonalDetail(participantAccountIDs[0]);
	}

However, the participants contains both the user and the current user, so the length is 0, thus the participantAccountIDs.length === 1 condition is never satisfied. This happens after we migrate from report.participantAccountIDs to report.participants.

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

Filter out current user from report.participants. We can also optionally replace participantAccountIDs.length === 1 with isOneOnOneChat.

if (isOneOnOneChat(report)) {
    const participantAccountIDs = Object.keys(report?.participants ?? {}).map(Number).filter((accountID) => accountID !== currentUserAccountID);
    return isOptimisticPersonalDetail(participantAccountIDs[0]);
}

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~018004b4dcf5d57a3b

[melvin-bot]

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

[ZhenjaHorbach]

Thank you for your proposal @bernhardoj !

Your proposal makes sense

But I’m not sure, but perhaps this might not be the best idea
Because after we open the chat we will have a non-clickable header and a user will not understand why it does not work
And this will last until the user waits for a response from the server

@laurenreidexpensify
What do you think about this ?

[bernhardoj]

Yeah, maybe it's not the best behavior, but just want to point out that it's how it works before (first introduced in #22691)

[laurenreidexpensify]

@Expensify/design curious for your take on this one wrt to the flow here and @ZhenjaHorbach's comment:

Because after we open the chat we will have a non-clickable header and a user will not understand why it does not work
And this will last until the user waits for a response from the server

Do you agree?

[dannymcclain]

Hmm, I'm not sure I totally understand what's going on. Why does the user change from an email address to "Hidden"?

[shawnborton]

Yeah, I don't quite understand that part either. @puneetlath I think you worked on some of the "Hidden" stuff previously, do you have an opinion here?

[ZhenjaHorbach]

Sorry for the misunderstanding
But Hidden is unexpected behavior that we need to prevent

But here it’s a little unclear what expected behavior we should have when we open a chat with an user with non-existing email for the first time until we receive a response from the server

1. We need to disable the header to prevent access to the Profile until we receive a response from the server (This was the intended behavior before the bug appeared.)

OR

2. Alternatively, we could allow access to the Profile with limited functionality until we receive a response from the server (As in Expected Result for this issue in description )

[bernhardoj]

Why does the user change from an email address to "Hidden"?

To add more information, when we start a chat with a new user, we optimistically create the user information on the FE (accountID, etc.). The BE then responds with different information and we clear the optimistic information to avoid keeping unused information.

So for example, the optimistic accountID is 1, but the real accountID sent from the BE is 2.

[melvin-bot]

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

[ZhenjaHorbach]

Not overdue
Waiting for clarification of the expected result

[melvin-bot]

📣 @bernhardoj 🎉 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 📖

[bernhardoj]

PR is ready

cc: @ZhenjaHorbach

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

• Disable navigating to profile page if the user is optimistic #44737

If no regressions arise, payment will be issued on 2024-07-17. 🎊

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

• @bernhardoj requires payment automatic offer (Contributor)
• @ZhenjaHorbach requires payment automatic offer (Reviewer)

[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:

• [@ZhenjaHorbach] The PR that introduced the bug has been identified. Link to the PR:
• [@ZhenjaHorbach] 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:
• [@ZhenjaHorbach] 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:
• [@ZhenjaHorbach] Determine if we should create a regression test for this bug.
• [@ZhenjaHorbach] 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.
• [@twisterdotcom] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[bernhardoj]

I'll request in ND once payment is due.

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.6-8 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Disable navigating to profile page if the user is optimistic #44737

If no regressions arise, payment will be issued on 2024-07-22. 🎊

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

• @bernhardoj requires payment automatic offer (Contributor)
• @ZhenjaHorbach requires payment automatic offer (Reviewer)

[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:

• [@ZhenjaHorbach] The PR that introduced the bug has been identified. Link to the PR:
• [@ZhenjaHorbach] 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:
• [@ZhenjaHorbach] 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:
• [@ZhenjaHorbach] Determine if we should create a regression test for this bug.
• [@ZhenjaHorbach] 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.
• [@twisterdotcom] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[bernhardoj]

The payment should be due tomorrow (07-17)

[bernhardoj]

Requested in ND.

[ZhenjaHorbach]

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:

• [@ZhenjaHorbach] The PR that introduced the bug has been identified. Link to the PR:

#40254

• [@ZhenjaHorbach] 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:

https://github.com/Expensify/App/pull/40254/files#r1680722584

• [@ZhenjaHorbach] 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:

NA

• [@ZhenjaHorbach] Determine if we should create a regression test for this bug.
• [@ZhenjaHorbach] 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.

Regression Test Steps

1. Start a new chat with a new user
2. Verify the header is disabled until the BE returns the correct information (the default avatar will be shown)

Do we agree 👍 or 👎?

[twisterdotcom]

Payment Summary:

• @bernhardoj paid $250 via NewDot Manual Request (Contributor)
• @ZhenjaHorbach paid $250 here (Reviewer)

[JmillsExpensify]

$250 approved for @bernhardoj