[HOLD for payment 2024-06-28] [$250] Send invoice - Error above Submit button is delayed by a moment when sending invoice without merchant

[m-natarajan]

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

---

issue found when verifying #42945
Version Number: 1.4.80-1
Reproducible in staging?: y
Reproducible in production?: n
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:

Action Performed:

1. Go to staging.new.expensify.com
2. Go to FAB > Submit expense > Manual.
3. Enter amount and select a workspace.
4. Without entering a merchant, click Submit.
5. Note that the error "Please enter a correct merchant." above the Submit button appears instantly with the error in Merchant row.
6. Go to FAB > Send invoice.
7. Enter amount and select a user.
8. Without entering a merchant, click Submit.

Expected Result:

The error "Please enter a correct merchant." above Submit button will appear instantly with the error in Merchant row.

Actual Result:

The error "Please enter a correct merchant." above Submit button appears after the error in Merchant row shows up.

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

Bug6504045_1717687714499.20240606_232459.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01c19982c3b14e4872
• Upwork Job ID: 1798787895149624495
• Last Price Increase: 2024-06-06
• Automatic offers:
• bernhardoj | Contributor | 102676340

Issue Owner

Current Issue Owner: @lschurr

[melvin-bot]

Triggered auto assignment to @yuwenmemon (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

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

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[m-natarajan]

@lschurr 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

[melvin-bot]

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

[melvin-bot]

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

[yuwenmemon]

This is very minor so I'm removing the blocker label.

[Krishna2323]

Proposal

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

Send invoice - Error above Submit button is delayed by a moment when sending invoice without merchant

What is the root cause of that problem?

shouldShowReadOnlySplits is false for invoice type transactions and when it is false we use debouncedFormError instead of formError which causes the delay.

App/src/components/MoneyRequestConfirmationList.tsx

Line 468 in 66870b4

const shouldShowReadOnlySplits = useMemo(() => isPolicyExpenseChat || isReadOnly || isScanRequest, [isPolicyExpenseChat, isReadOnly, isScanRequest]);

App/src/components/MoneyRequestConfirmationList.tsx

Line 816 in 66870b4

message={!shouldShowReadOnlySplits ? debouncedFormError : formError}

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

We should add isTypeInvoice to shouldShowReadOnlySplits check.

const shouldShowReadOnlySplits = useMemo(() => isPolicyExpenseChat || isReadOnly || isScanRequest || isTypeInvoice, [isPolicyExpenseChat, isReadOnly, isScanRequest,isTypeInvoice]);

What alternative solutions did you explore? (Optional)

[bernhardoj]

Proposal

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

The form error shows late on the send invoice page.

What is the root cause of that problem?

When read only split is false, we will use the debounced form error.

App/src/components/MoneyRequestConfirmationList.tsx

Line 816 in 1426c4e

message={!shouldShowReadOnlySplits ? debouncedFormError : formError}

App/src/components/MoneyRequestConfirmationList.tsx

Line 468 in 1426c4e

const shouldShowReadOnlySplits = useMemo(() => isPolicyExpenseChat || isReadOnly || isScanRequest, [isPolicyExpenseChat, isReadOnly, isScanRequest]);

It assumes that if read only split is false, then it's an editable split request, but it's wrong.

In our case, the invoice is detected as shouldShowReadOnlySplits. shouldShowReadOnlySplits is the condition of whether, if a request is a split, is it read only or not, but it doesn't tell whether the request is a split or not. So, shouldShowReadOnlySplits should only be used if it's a split type request.

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

Update the condition below to,

App/src/components/MoneyRequestConfirmationList.tsx

Line 816 in 1426c4e

message={!shouldShowReadOnlySplits ? debouncedFormError : formError}

message={(isTypeSplit && !shouldShowReadOnlySplits) ? debouncedFormError : formError}

You can see other usages where it's only being used for split request, for example,

App/src/components/MoneyRequestConfirmationList.tsx

Lines 470 to 476 in 1426c4e

	const splitParticipants = useMemo(() => {
	if (!isTypeSplit) {
	return [];
	}
	const payeeOption = OptionsListUtils.getIOUConfirmationOptionsFromPayeePersonalDetail(payeePersonalDetails);
	if (shouldShowReadOnlySplits) {

[mollfpr]

I feel updating shouldShowReadOnlySplits is too risky and we will make sure that the current logic for other cases is still working fine, while the issue only happens for the FormHelpMessage.

So I think the proposal from @bernhardoj is more feasible for this issue.

🎀 👀 🎀 C+ reviewed!

[melvin-bot]

Current assignee @yuwenmemon is eligible for the choreEngineerContributorManagement assigner, not assigning anyone new.

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

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

• Fix error above Submit button is delayed by a moment when sending invoice without merchant #43455

If no regressions arise, payment will be issued on 2024-06-28. 🎊

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

• @mollfpr requires payment through NewDot Manual Requests
• @bernhardoj 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:

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

[lschurr]

Payment summary for tomorrow, 6/28:

• Contributor: $250 @bernhardoj (Paid in Upwork)
• Contributor+: $250 @mollfpr (please request in Newdot)

[lschurr]

This is complete.

[mollfpr]

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

#40386

[@mollfpr] 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/40386/files#r1662870768

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

I think the regression step should be enough.

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

1. Press FAB > Send Invoice
2. Enter any amount and select any participant
3. On the confirmation page, submit the request without a merchant
4. Verify the merchant error and the error above the Submit button are shown at the same time
5. 👍 or 👎

[JmillsExpensify]

$250 approved for @mollfpr. Also re-opening this issue for the regression test.

[JmillsExpensify]

Quick update on the payment approval. This is @mollfpr.

[lschurr]

Thanks! I've opened a request for a new QA test.