[HOLD for payment 2024-06-20] [HOLD for payment 2024-06-18] [HOLD for payment 2024-06-13] send invoice-Unexpected error shown while sending invoice

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

---

Version Number: 1.4.79-2
Reproducible in staging?: y
Reproducible in production?: n
If this was caught during regression testing, add the test name, ID and link from TestRail: n/a
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:

Pte-condition: login with account which has workspaces

1. Go to https://staging.new.expensify.com/
2. Tap fab -- send invoice
3. Enter an amount and tap next
4. Select an user
5. Tap send
   EXPECTED RESULT
   ACTUAL RESULT

Expected Result:

Unexpected error must not be shown while sending invoice.

Actual Result:

Unexpected error shown while sending invoice.

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

Bug6501954_1717527623387.invoi.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @puneetlath

[melvin-bot]

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

[melvin-bot]

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

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

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

[roryabraham]

discussed in slack to confirm this is a legit blocker, looks like the answer is probably yes

[roryabraham]

I think this may be just a matter of clearer error reporting. The error is saying that it's an invalid invoice recipient:

[roryabraham]

The error is being thrown here.

The problem here is that the front-end is not sending receiverEmail or receiverInvoiceRoomID in the request.

[roryabraham]

The reason neither receiverEmail nor receiverInvoiceRoomID in the SendInvoice request is because here invoiceChatReport looks like this:

So when we try to send the invoiceChatReport.reportID, it's undefined.

We may also have been able to avoid this at compile-time by leveraging type-fest's RequireAtLeastOne utility in the SendInvoiceParams type:

diff --git a/src/libs/API/parameters/SendInvoiceParams.ts b/src/libs/API/parameters/SendInvoiceParams.ts
index 55a82e3103..f8ba0647fb 100644
--- a/src/libs/API/parameters/SendInvoiceParams.ts
+++ b/src/libs/API/parameters/SendInvoiceParams.ts
@@ -1,20 +1,25 @@
-type SendInvoiceParams = {
-    senderWorkspaceID: string;
-    accountID: number;
-    receiverEmail?: string;
-    receiverInvoiceRoomID?: string;
-    amount: number;
-    currency: string;
-    comment: string;
-    merchant: string;
-    date: string;
-    category?: string;
-    invoiceRoomReportID?: string;
-    createdChatReportActionID: string;
-    invoiceReportID: string;
-    reportPreviewReportActionID: string;
-    transactionID: string;
-    transactionThreadReportID: string;
-};
+import type {RequireAtLeastOne} from 'type-fest';
+
+type SendInvoiceParams = RequireAtLeastOne<
+    {
+        senderWorkspaceID: string;
+        accountID: number;
+        receiverEmail?: string;
+        receiverInvoiceRoomID?: string;
+        amount: number;
+        currency: string;
+        comment: string;
+        merchant: string;
+        date: string;
+        category?: string;
+        invoiceRoomReportID?: string;
+        createdChatReportActionID: string;
+        invoiceReportID: string;
+        reportPreviewReportActionID: string;
+        transactionID: string;
+        transactionThreadReportID: string;
+    },
+    'receiverEmail' | 'receiverInvoiceRoomID'
+>;
 
 export default SendInvoiceParams;

[roryabraham]

Confirmed that this is a front-end blocker, not a back-end blocker.

[roryabraham]

@cristipaval pulling you in to help push this forward while I'm sleeping. If you can't get to it sooner, I'll pick this back up in the morning

[VickyStash]

Hi, I'm Viktoryia from Callstack - expert contributor group - and I would like to work on this issue.

[VickyStash]

I've investigated it a little bit more and found what has changed to cause this problem:

• as @roryabraham has mentioned above, the reason of the problem is that the app provides receiverInvoiceRoomID = undefined, because the report looks like this and has not reportID:
  
• But why we have this data for the report inside the onyx? It's caused by the updates of this PR. It has updated withWritableReportOrNotFound to call OpenReport command.
  

  App/src/pages/iou/request/step/withWritableReportOrNotFound.tsx

  Lines 64 to 72 in 432c2e7

  	useEffect(() => {
  	if (Boolean(report?.reportID) || !route.params.reportID) {
  	return;
  	}
  	ReportActions.openReport(route.params.reportID);
  	// eslint-disable-next-line react-hooks/exhaustive-deps
  	}, []);

  
  And IOURequestStepAmount is wrapped into this HOC. So anytime a user tries to create an expense/invoice OpenReport command is called, and a report with errorFields is put into the Onyx.

403_err1.mp4

---

But regardless of this, I think it makes sense to:

• improve the check inside IOU.sendInvoice to check for invoiceChatReport.reportID
• update SendInvoiceParams to use type-fest's RequireAtLeastOneas it was proposed above

[VickyStash]

@roryabraham I've prepared a Draft PR with the changes you suggested, it fixes the error as well

[puneetlath]

Confirmed it's fixed on staging. Checking off.

[roryabraham]

Pulling in @mananjadhav for the C+ review payment

[kbecciv]

Issue is no longer reproduced

Screenrecorder-2024-06-06-16-19-29-763.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.79-11 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• [CP Staging] Update SendInvoiceParams typing #43095

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

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

• @mananjadhav requires payment through NewDot Manual Requests
• @VickyStash does not require payment (Contractor)

[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.
• [@puneetlath] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[melvin-bot]

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

• [CP Staging] Update SendInvoiceParams typing #43095

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

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

• @mananjadhav requires payment through NewDot Manual Requests
• @VickyStash does not require payment (Contractor)

[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.
• [@puneetlath] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[mananjadhav]

This should be paid out tomorrow. I am not sure why the date shows 2024-06-18. This was deployed a week back.

[puneetlath]

Payment summary:

• C+ - @mananjadhav - $250

[melvin-bot]

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

• [CP Staging] Update SendInvoiceParams typing #43095

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

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

• @mananjadhav requires payment through NewDot Manual Requests
• @VickyStash does not require payment (Contractor)

[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.
• [@puneetlath] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[JmillsExpensify]

$250 approved for @mananjadhav