[HOLD for payment 2024-06-20] [HOLD for payment 2024-06-18] [HOLD for payment 2024-06-11] [HOLD for payment 2024-06-06] Distance rates - Default rate input is 0 instead of actual amount for newly created WS

[m-natarajan]

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.77-0
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 offline.
3. Create a new workspace.
4. Go to More features.
5. Enable Distance rates.
6. Go to Distance rates.
7. Click on the default rate.
8. Click Rate.

Expected Result:

The rate amount input will display the actual amount (production behavior).

Actual Result:

The rate amount input displays 0 instead of the actual amount.

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

Bug6495253_1716998312348.20240529_235104.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @JmillsExpensify

[melvin-bot]

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

[melvin-bot]

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

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

[francoisl]

I can still reproduce on the latest version of main. I think the root cause was PR #42426, reverting it locally fixes the issue for me locally.

cc @bernhardoj @ikevin127 if you're around and can think of a fix, otherwise I've got a draft revert PR above ^

[francoisl]

For the default rate 0.655, the updated version of the function calculateAmountLength() returns ... 11, whereas for the rate 0.670 coming from the API when you're online, it returns 3.
validateAmount() is called with amountMaxLength: 10, which is why the function is returning false when you're offline.

[ikevin127]

@francoisl If this is a blocker that needs to be handled asap then I'd suggest the revert since the code changes of the PR are minimal, then @bernhardoj won't be time constrained to re-work the solution.

Otherwise I'd wait for their input and possible follow-up fix.

[francoisl]

Sounds good, revert PR is in review.

If it helps, I narrowed the issue a little more, it's now coming from

App/src/libs/MoneyRequestUtils.ts

Lines 48 to 50 in 02b0c5e

	if (/\D/.test(absAmount)) {
	return CONST.IOU.AMOUNT_MAX_LENGTH + 1;
	}

because for values with 3 decimals like 0.655, the new absAmount is now 65.5, and so the /\D/.test is now returning true. Before the update, the absAmount would have been 655, and so we didn't return early in that block.

I guess the solution is to change that regex to allow decimal values, but I'll let you guys double-check.

[kavimuru]

Fixed in the version 77-3

Screen_Recording_20240530_034428_New.Expensify.1.mp4

[bernhardoj]

@francoisl correctly pointed out the root cause, it's the old regex here.

App/src/libs/MoneyRequestUtils.ts

Lines 48 to 50 in f6aa6c2

	if (/\D/.test(absAmount)) {
	return CONST.IOU.AMOUNT_MAX_LENGTH + 1;
	}

The calculation that we did is already correct, but the regex above matches the decimal separator (.) because 0.655 is 65.5 cents which still contains a dot.

The regex above is added in this PR to prevent NaN, Infinity, and number with scientific notation (1+e26). So, I updated the regex to be more specific.

A new PR is here

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

• [CP Staging] Revert "Merge pull request #42426 from bernhardoj/fix/42084-limi-amount-to-8-digit" #42783

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

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

• [@francoisl] The PR that introduced the bug has been identified. Link to the PR: Fix user can submit 10-digit amount and gives an unexpected error #42426
• [@francoisl] 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: [HOLD for payment 2024-06-20] [HOLD for payment 2024-06-18] [HOLD for payment 2024-06-11] [HOLD for payment 2024-06-06] Distance rates - Default rate input is 0 instead of actual amount for newly created WS #42780 (comment)
• [@francoisl] 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
• [@francoisl] Determine if we should create a regression test for this bug. Edge case imo, not needed
• [@francoisl] 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. N/A
• [@JmillsExpensify] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[francoisl]

The final fix for this was just merged. This was for a regression that was originally handled internally, and then the author and C+ from the initial PR fixed it, so I believe no payment is required.

[melvin-bot]

Skipping the payment summary for this issue since all the assignees are employees or vendors. If this is incorrect, please manually add the payment summary SO.

[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. 🎊

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

• [@francoisl] The PR that introduced the bug has been identified. Link to the PR:
• [@francoisl] 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:
• [@francoisl] 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:
• [@francoisl] Determine if we should create a regression test for this bug.
• [@francoisl] 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.
• [@JmillsExpensify] 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. 🎊

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

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

[melvin-bot]

Skipping the payment summary for this issue since all the assignees are employees or vendors. If this is incorrect, please manually add the payment summary SO.

[melvin-bot]

@JmillsExpensify, @francoisl Whoops! This issue is 2 days overdue. Let's get this updated quick!

[francoisl]

Checklist already completed above and no payments required, closing.