[HOLD for payment 2024-01-26] [$500] Settings - Red dot remains after error is cleared

[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.12-0
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 #31713

Action Performed:

Pre-requisite: user must be logged in

1. On staging, enable "Simulate failing network requests" in Settings > Preferences
2. Go to Settings > Profile > Contact method
3. Add a phone number as a new contact method
4. Wait for the pending add operation to fail
5. Once you see the red dot, click on the contact method and clear the error

Expected Result:

The red dot should disappear after the error is cleared

Actual Result:

The red dot remains on user avatar on the home screen and in settings

Workaround:

Unknown

Platforms:

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

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• Windows: Chrome
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6312254_1702503451411.bandicam_2023-12-13_15-07-14-733.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~012ec660a67cb6d223
• Upwork Job ID: 1735053356937179136
• Last Price Increase: 2024-01-03
• Automatic offers:
• ntdiary | Reviewer | 28089273
• tienifr | Contributor | 28089274

[melvin-bot]

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

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~012ec660a67cb6d223

[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 - @ntdiary (External)

[AmjedNazzal]

Proposal

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

All - Settings - Red dot remains after error is cleared

What is the root cause of that problem?

In deleteContactMethod, we are clearing errorFields.deletedLogin but we aren't clearing errorFields.addedLogin which is a part of the failureData of addNewContactMethodAndNavigate.

When we delete a contact method, we expect a green dot to show up while the deletion is being processed, this is added intentionally by using pendingFields.deletedLogin: CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE as shown below in the code, however this green dot is override by red dot because of errorFields.addedLogin

App/src/libs/actions/User.js

Lines 186 to 200 in fe2d0d1

	function deleteContactMethod(contactMethod, loginList) {
	const oldLoginData = loginList[contactMethod];
	const optimisticData = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.LOGIN_LIST,
	value: {
	[contactMethod]: {
	partnerUserID: '',
	errorFields: {
	deletedLogin: null,
	},
	pendingFields: {
	deletedLogin: CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,

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

We should clear that errorField on contact method deletion so the red dot doesn't show up during the deletion process

function deleteContactMethod(contactMethod, loginList) {
    ....
    value: {
        [contactMethod]: {
            ....
            errorFields: {
                deletedLogin: null,
                addedLogin: null,
            },

Result

Screen.Recording.2023-12-14.at.2.31.09.AM.mov

[sfurqan2]

Proposal

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

Red dot remains after error is cleared when network connection is simulating slow network requests

What is the root cause of that problem?

The root cause of the problem is that in Contact Page there is an additional check which hides new contact requests with pendingAction "delete".

const hideChildren = shouldHideOnDelete && !isOffline && pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE && !hasErrors;

However, this check is missing from userUtils "hasLoginListError" function.

function hasLoginListError(loginList: Record<string, Login>): boolean {
    return Object.values(loginList).some((loginData) => Object.values(loginData.errorFields ?? {}).some((field) => Object.keys(field ?? {}).length > 0));
}

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

Logic on both ends should be kept consistent so I would suggest we implement the same checks in userUtils and call it. This will maintain the DRY principle as well as is easier to maintain.

What alternative solutions did you explore? (Optional)

N/A

[melvin-bot]

📣 @sfurqan2! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[sfurqan2]

Contributor details
Your Expensify account email: sfurqan1999@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~0163c31a5a31c72f3f

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[tienifr]

Proposal

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

The red dot remains on user avatar on the home screen and in settings

What is the root cause of that problem?

When adding login and have failure, the addedLogin error field will have value here. When we delete the contact method, it should have cleared all Onyx data here after successful API request, but because we're still turning on the "Simulate failing network requests", the delete contact method request remains pending for a while, so the red dot shows because the addedLogin error field is still there.

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

As we can see, we're making a redundant and unnecessary API call here, since the contact method fails to be added, there's no point in calling 'DeleteContactMethod' when deleting it. We should only call 'DeleteContactMethod' if the contact method was added successfully and it's stored in the back-end.

This also leads to the login data still being available while the API call is being made, causing this issue.

We should treat this as any other case where we clear the error, we should clear the Onyx data only because the action fails and there's nothing to so in back-end side. In here, when removing contact method that failed to be added, clearing in Onyx is enough.

if (oldLoginData.errorFields.addedLogin) {
    Navigation.goBack(ROUTES.SETTINGS_CONTACT_METHODS.route);
    // If the contact method failed to be added, we can just remove it from Onyx
    Onyx.merge(ONYXKEYS.LOGIN_LIST, {
        [contactMethod]: null,
    });
    return;
}

What alternative solutions did you explore? (Optional)

We can clear the errorFields optimistically when trying to delete contact method, then potentially restore it if the contact method deletion fails, this will make sure the contact method with proper error is shown again if the contact deletion itself fails, as mentioned here.

In here

errorFields: null,

In here

errorFields: {
    ...oldLoginData.errorFields,
    deletedLogin: null,
},

Or we can remove and restore only the addedLogin error if we want to.

[bernhardoj]

Immediately clear the onyx when add fails is intentionally removed here

[tienifr]

@bernhardoj thanks for the link! But I think it was removed because we assumed that it won't cause any issue, but it clearly does cause issue here and it wouldn't hurt us if reintroducing it.

[melvin-bot]

@ntdiary, @michaelhaxhiu Huh... This is 4 days overdue. Who can take care of this?

[ntdiary]

under review.

[ntdiary]

Immediately clear the onyx when add fails is intentionally removed here

Based on the goal of this PR, I don't think we should revert the local condition.
Additionally, this issue may not be a bug.
After we click the Remove button, because we have enabled Simulate failing network requests, the DeleteContactMethod api should also fail, the removed contact method will also reappear later, I think it is expected behavior. However, it seems that we did not wait for it to complete. 😂

test.mp4

Because our app defaults to retrying requests 10 times, we can see from the video that it takes a long time for the results of add and delete to be displayed. By the way, if we want to improve that delay, we should think from a more general perspective, not just for this case. 🙂

[melvin-bot]

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

[AmjedNazzal]

@ntdiary Any feedback on my proposal?

[ntdiary]

I think we need to clarify the expected result in the OP first.
Actually, because we have already enabled Simulate failing network requests, so clear the error would also fail (automatically retried 10 times), as shown in my previous video, the cleared contact method was displayed again. In this situation, having the red dot displayed is expected result.

cc @lanitochka17, @michaelhaxhiu

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[danieldoglas]

@tienifr @ntdiary can you please take a look into #34758 and check if it's related ? cc @dangrous

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

• fix: Red dot remains after error is cleared #34125

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

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

• @ntdiary requires payment automatic offer (Reviewer)
• @tienifr requires payment automatic offer (Contributor)

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

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

[ntdiary]

@tienifr @ntdiary can you please take a look into #34758 and check if it's related ? cc @dangrous

@danieldoglas. Has provide an explanation in Issue #34758 (comment). :)

[dangrous]

Hi! I just wanted to call it out here - I'm closing out #34758 as not a bug, but I'm pretty sure it means that QA was never able to successfully QA this issue. It would be great if y'all could make sure this works as expected on this issue!

[danieldoglas]

@ntdiary let's do the bugzero checklist here

[michaelhaxhiu]

Next step is with @ntdiary to do the regression steps

[ntdiary]

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:

• [@ntdiary] The PR that introduced the bug has been identified. Link to the PR: Show all Expensify logins in Contact Methods page & view each in new Contact Method Details page #15204
• [@ntdiary] 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/15204/files#r1473781500
• [@ntdiary] 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: No need
• [@ntdiary] Determine if we should create a regression test for this bug. No need
• [@ntdiary] 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. No need
• [@michaelhaxhiu] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

I think this is a small edge case we overlooked during the development of the contact details page, so it's okay to just leave a comment in the original PR, no regression test is needed. :)

[melvin-bot]

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

[danieldoglas]

cc @miljakljajic can you please proceed with the payment on this issue? Thanks!

[miljakljajic]

Paid and paid!