[HOLD for payment 2024-06-20] [HOLD for payment 2024-06-18] [$250] mWeb - IOU - Creating a split expense with IQD currency & 10 digit amount unexpected error shown

[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.73
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4554848
Issue reported by: Applause - Internal Team

Action Performed:

1. Go to https://staging.new.expensify.com/home
2. Tap on a new 1:1 report
3. Create a split expense with IQD currency and 10 digit amount 2000000000

Expected Result:

If 10 digit amount are not allowed, user must not be allowed to create expense. If user allowed to create expense, then unexpected error must not be shown

Actual Result:

Creating a split expense with IQD currency & 10 digit amount unexpected error displayed

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

Bug6479391_1715607502707.iqd.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01894cc4ac52447ce7
• Upwork Job ID: 1790841039070965760
• Last Price Increase: 2024-05-15
• Automatic offers:
• ikevin127 | Reviewer | 0
• bernhardoj | Contributor | 0

Issue Owner

Current Issue Owner: @trjExpensify

[melvin-bot]

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

@trjExpensify 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-split

[bernhardoj]

Proposal

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

Creating a new expense with a 10 digit gives an unexpected error.

What is the root cause of that problem?

This issue not only happens with IQD currency but with any currency that has no decimals, such as JPY. We are validating the amount length here,

App/src/libs/MoneyRequestUtils.ts

Lines 58 to 64 in f8a30a1

	function validateAmount(amount: string, decimals: number, amountMaxLength: number = CONST.IOU.AMOUNT_MAX_LENGTH): boolean {
	const regexString =
	decimals === 0
	? `^\\d+(,\\d*)*$` // Don't allow decimal point if decimals === 0
	: `^\\d+(,\\d*)*(\\.\\d{0,${decimals}})?$`; // Allow the decimal point and the desired number of digits after the point
	const decimalNumberRegex = new RegExp(regexString, 'i');
	return amount === '' || (decimalNumberRegex.test(amount) && calculateAmountLength(amount, decimals) <= amountMaxLength);

and the default max length is 10.

App/src/CONST.ts

Line 1557 in f8a30a1

AMOUNT_MAX_LENGTH: 10,

We calculate the amount length using calculateAmountLength function.

App/src/libs/MoneyRequestUtils.ts

Lines 43 to 46 in f8a30a1

	function calculateAmountLength(amount: string, decimals: number): number {
	const leadingZeroes = amount.match(/^0+/);
	const leadingZeroesLength = leadingZeroes?.[0]?.length ?? 0;
	const absAmount = parseFloat((Number(stripCommaFromAmount(amount)) * 10 ** decimals).toFixed(2)).toString();

In calculateAmountLength, we multiply the amount with 10 to the power of the number of decimals allowed on a currency. So, if the currency allows 2 decimals, then it will be multiplied by 100, that's why we can only input 8 digit length for currency like USD. But if the currency doesn't allow decimal, such as IQD, then we can input 10 digit length.

However, in the BE, all amounts are in cent, so the 10-digit length will be 12 digit length, and BE will return an error for it.

The wrong length calculation logic is changed in #34849

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

Always multiply the amount with 100 to convert it to cents instead of depending on the decimals allowed on a currency, just like what we did for the first time in #5243.

[trjExpensify]

Whoops, slipped through the cracks. I agree there should be front-end validation to match here.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~01894cc4ac52447ce7

[melvin-bot]

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

[ikevin127]

@bernhardoj's proposal makes sense to me. The root cause was identified, together with the offending PR and the proposed solution looks solid.

🎀👀🎀 C+ reviewed

[melvin-bot]

Triggered auto assignment to @marcochavezf, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[melvin-bot]

@marcochavezf, @trjExpensify, @ikevin127 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[ikevin127]

Overdue notes: Awaiting CME review / assignment for the selected proposal.

[trjExpensify]

Marco is out for a few days. @mountiny mind doing the honours on this?

[mountiny]

Thanks, the analysis makes sense to me too

[melvin-bot]

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

Offer link
Upwork job

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

[melvin-bot]

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

• Fix user can submit 10-digit amount and gives an unexpected error #42426

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

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

• @bernhardoj requires payment automatic offer (Contributor)
• @ikevin127 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:

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

[ikevin127]

@trjExpensify False alarm, the initial PR was reverted - now we're working on the second one.

[trjExpensify]

Cool, removing the payment hold. Thanks for the heads up!

[ikevin127]

2nd PR was just merged, hopefully this will do without any other regressions🤞

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

• #2 - Fix user can submit 10-digit amount and gives an unexpected error #42815

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

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

• @bernhardoj requires payment automatic offer (Contributor)
• @ikevin127 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:

• [@ikevin127] The PR that introduced the bug has been identified. Link to the PR:
• [@ikevin127] 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:
• [@ikevin127] 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:
• [@ikevin127] Determine if we should create a regression test for this bug.
• [@ikevin127] 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.
• [@trjExpensify] 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.82-4 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• #2 - Fix user can submit 10-digit amount and gives an unexpected error #42815

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

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

• @bernhardoj requires payment automatic offer (Contributor)
• @ikevin127 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:

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

[ikevin127]

• [@ikevin127] The PR that introduced the bug has been identified. Link to the PR: #34849.
• [@ikevin127] 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: #34849 (comment).
• [@ikevin127] 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: N/A
• [@ikevin127] Determine if we should create a regression test for this bug.
• [@ikevin127] 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 Proposal

1. Open the FAB menu.
2. Create a Split expense and select the IQD currency.
3. Verify that we cannot enter an amount with more than 8 digits. (e.g. 12345678)
4. Submit the Split expense.
5. Verify that the expense request is submitted successfully without any errors being shown.

Do we agree 👍 or 👎.

[ikevin127]

⚠️ Not sure why the automation added the second HOLD date her, since the PR was deployed 4 days ago according to #42815 (comment) -> therefore the [HOLD for payment 2024-06-18] is the correct payment date.

Summary:

• 1st PR was reverted due to regression -> no compensation due for contributor / reviewer
• 2nd PR was deployed to production 4 days ago -> compensation due for contributor / reviewer on 2024-06-18

cc @trjExpensify

[trjExpensify]

Not sure where 4 days ago is coming from, but if we're talking about these two PRs (1, 2), I agree it's due for payment now.

Confirming that as follows:

• $125 to @bernhardoj for the fix (minus 50% for the regression that caused the revert)
• $125 to @ikevin127 for the C+ review (minus 50% for the regression that caused the revert)

Let me know if I'm missing something, and I'll settle up with you both once confirmed.

[trjExpensify]

Cool, settled up!